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I. INTRODUCTION 



The purpose of this thesis is to design, develop and implement a personnel locator 
system at the Naval Postgraduate School (NPS). The locator will provide information 
such as email addresses, phone and fax numbers, and building and office locations, as 
well as facilities such as hotlinks for email applications and homepages. The impetus for 
the NPS Locator system was twofold. The first spawned from the “Strategic Plan for 
Computing at the Naval Postgraduate School,” published late 1995. In an effort to 
improve the computing infrastructure at NPS, the Associate Provost of Computing was 
interested in testing the viability of intranet technology as an application deployment 
platform for campus-wide systems. A locator system was selected as one of the first 
applications because of its relative simplicity, and because its usefulness should attract 
users, resulting in exposure for intranet technology at NPS. The second impetus arose 
from, simply, the lack of any existing accurate and complete directory system at the time 
this study was conceived. 

A. THE NPS COMPUTING ENVIRONMENT 

The Strategic Plan mentioned above addresses many different facets of the NPS 
computing environment. Two issues that are relevant to this thesis are the 
communications network and administrative application development. The network, as 
the document states, “is fragmented and unreliable, held together by bailing wire and 
sweat.” The Associate Provost’s goal is to have a network that is, “ubiquitous, reliable, 
transparent, and (that is) easy to use as a modem telephone system.” The network is 
fragmented because, in the past, the enterprise perspective of the network was not 
acknowledged. Networks were built and administered independent of each other, usually 
along departmental lines. This independent growth resulted in a network that consists of 
at least four different network operating systems (NOS), various resource sharing and 
access capabilities, minimal interoperability, various email naming schemes, and different 
directory systems for each NOS. 

The development of administrative applications also fell victim to this 
decentralized and haphazard approach to information technology management. 
Applications were developed and data sources created within an organizational unit 
without consideration of needs outside of the particular organizational unit. This lead to 
duplication of effort and did not foster interoperability. These “stovepipe” applications 
have different data requirements, different hardware requirements, and, for the most part, 
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are not widely accessible from outside the organizational unit in which they were 
developed. 

These issues provoked a grass-roots exploration into intranet technology from 
several faculty, staff, and students including the Associate Provost of Computing. 
Several independent theses have been written to address various aspects of intranet 
technology and how it can be applied in the NPS computing environment. Chapter II 
discusses the benefits and considerations of intranets. Again, the focus of this work is to 
build an intranet application, the NPS Locator directory system, using industrial strength 
tools that are already being used by the NPS computing staff to serve as a demonstration 
of intranet viability at NPS. 

B. SURVEY OF NPS DIRECTORIES 

At the time this study was undertaken the directories that existed at NPS were 
inaccurate and incomplete. Accuracy in this context refers not only to phone numbers, 
email addresses, and descriptive information being outdated and incorrect, but also to 
misspellings of the data. Completeness of the directory refers to the content of the 
directories. For example, one directory, the phone book, only provides phone numbers, 
whereas the UNIX “finger” application may only provide email information. A complete 
directory should provide information to communicate or “locate” a person by all available 
means. 

The preexisting directories included the NPS paper phone book, UNIX “ph” and 
“finger” programs, proprietary network directories (e.g., Banyan Vines StreetTalk 
Directory) and a variety of uncoordinated and unmanaged Web directories, some 
containing departmental information only. These directories also required frequent 
manual updates if they were to stay current. 

These preexisting directories varied greatly in many aspects. By reviewing the 
directories, and correlating notes on their strengths and weaknesses, seven characteristics 
of directory systems became apparent. The characteristics later drove the requirements 
and design of the NPS Locator Prototype. The characteristics are as follows: 

1. Scope 

The scope of the directory refers to the type entities listed. For example, many of 
the directories only have staff and faculty in them. Others only have staff and faculty 
from within a particular department. The desired scope includes faculty, staff and 
students from the entire Naval Postgraduate School population. 
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2. Completeness 



The completeness of the directory refers to the attributes listed on each entity in 
the directory. For example, some directories only list phone number, office and 
department. The desired list of entity attributes were chosen by testing each of them 
against the following premise: An attribute must enhance or enable either the process of 
locating an individual or the actual communication with the individual. For example, if 
an individual needs to communicate with another, the office number may enable the 
process by letting the first individual physically locate the second individual. A 
photograph may also aid in the process if the individuals have never met in person 
previously. 

3. Accessibility 

Accessibility is concerned, in part, with who has authorization to use the 
directory. Many of the directories were limited to NPS personnel use, others were 
available to the Internet community. In addition, accessibility deals with the ease of 
access to the directory. Some directories were deeply hidden in a department’s own Web 
pages, and not publicly known or advertised to the rest of NPS. The directory should be 
available for all to use, with perhaps, various views depending on whether access is from 
outside or from within the NPS intranet. Furthermore, the directory should be easy to get 
to and should be made known to all of NPS. The most obvious location for an NPS-wide 
directory would be on the NPS homepage. 

4. Platform Dependence 

The directory should be available on a platform that is readily available to the 
largest population at NPS. This requirement unequivocally points to the Web as the 
platform of choice, since most NPS personnel have access to the Internet and the Web. 
Some of the directories reviewed either required the user to be on a proprietary LAN or 
required the user to use a particular operating system. For example, users can only access 
the StreetTalk Directory System from a Banyan Vines network client. 

5. Updates 

All of the directories surveyed required manual updating. Few, if any, had any 
regular update schedule. It is important to note, however, that most of the directories 
only contained staff and faculty listings, which contain rather static attributes. The 
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student population changes every quarter, and therefore provides more of a challenge to 
the directory update issue. It is preferable to automate the update process for two reasons. 
Firstly, updating the directory would most probably be a collateral duty for the 
responsible person, and certainly would not receive first priority. Maintaining a directory 
manually can be a tedious undertaking, especially if the directory is robust with 
information from a variety of data sources. With an automated update process, increasing 
the frequency of updates adds no burden to an individual, and because it is automated, it 
can be run at off-peak hours, therefore not impacting on NPS computer resources during 
peak hours. 

6. Data Sources 

The surveyed directories used a variety of data sources. Some directories received 
their data from the data owners initially, but then did not refresh that data on a regular 
basis, if at all. Others used second-hand data sources, such as departmental databases, 
which probably originated from the data owners. Again, no update method was in place 
to synchronize the data with the data owner’s data source. Still others created their data 
locally. 

The desired data sources are those that reside with the data owners. The data 
owners should have the most accurate and update information on the entities that they are 
responsible for. For example, the Human Resources Office (HRO) should have the most 
accurate information for civilian staff and faculty. This is not necessarily true for all 
attributes. For example, civilian faculty homepage addresses and class schedules would 
not be under the HRO ownership. The Registrar would own the class schedules and 
perhaps the computing center would own the homepage information. The data ownership 
issue assumes that the owner is properly maintaining the data. 

7. User Interface 

Finally, the user interfaces of the surveyed directories varied greatly. Some were 
command-line oriented, such as the “ph” interface, which is clumsy and not very 
powerful. Others varied between DOS menu systems and Windows point-and-click 
interfaces with varying degrees of complexity and usefulness. A few Web-based 
directories had good interfaces that were indeed easy to use. 

A directory should be easy to use and understand. The Web browser, with its 
point-and-click nature, provides users with an intuitive way to navigate through 
applications and locate the information they need using a common look and feel. The 
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directory’s interface design within the browser still requires thought, however, to ensure 
it is predictable and intuitive. 

C. THESIS ORGANIZATION 

This thesis has two main logical parts. The first part looks at intranets, providing 
a fairly thorough introduction into the technology and into the benefits and considerations 
of implementing an intranet. In addition, a generic web application architecture is 
discussed to provide some background into the architecture of the NPS Locator System. 

The second logical part explains the development of the NPS Locator from 
requirements through the functional capabilities of the prototype implementation. The 
outline of this thesis is, therefore, as follows: 

• Chapter I. Introduction. This chapter provides an overview of the paper and 
discusses preexisting directories at NPS. 

• Chapter II. Introduction to Intranets. This chapter introduces intranet 
technology, its benefits and considerations, and ends with a discussion of a 
common web application architecture. 

• Chapter III. NPS Locator Development. Chapter III provides the central 
focus of this thesis, the development of the NPS Locator System. This chapter 
reviews the requirements, tools, architecture, and functional aspects of the 
Locator. 

• Chapter IV. Conclusion and Recommendations. 
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II. INTRODUCTION TO INTRANETS 



The NPS Associate Provost of Computing is not alone with his interest in intranet 
technology. Numerous corporations and government installations are aggressively 
building intranets within their organizations. This interest comes on the heels of the 
recent success of the Internet and the World Wide Web (WWW). Many organizations 
want to exploit this inexpensive Web technology (Web browsers and Web servers). This 
section will define intranet, as well as discuss the technology and the benefits that this 
technology provides. 

A. INTRANET DEFINED 

An intranet is an internal network based on the same technologies used on the 
Internet and the World Wide Web. The Internet is the global internetwork (i.e., network 
of networks) that links tens of thousands of organizations — government, commercial and 
educational — from all over the globe. The Internet began as a Department of Defense 
(DOD) project in the late 1960’s. The growing importance of computers at that time gave 
rise to multiple challenges both in sharing information among different locations with 
different hardware and with keeping information intact during potential network 
disruptions at an individual site. The project resulted in the building of a network that 
interconnected various educational institutions and government installations. This 
network was called ARPANET (Advanced Research Projects Agency Network), which 
evolved into what now is known as the Internet. 

The Internet utilizes the TCP/IP (Transmission Control Protocol/Intemet 
Protocol) suite to interconnect these various computers and networks. IP allows these 
distributed networks to route and pass information to each other independently, so if one 
site is down the information can be routed through alternate sites to its final destination. 
The wide use of IP protocol, and hence the Internet, has made IP a de facto standard. 
(Telleen, 1996) 

Web technology has its roots in research carried out at the European Particle 
Physics Laboratory, CERN, in the early 1990’s. This project focused on a way of sharing 
information using hypertext links. Hypertext links are special codes that are embedded in 
a document that provide a way to jump to another part of the same document or to a 
different document. Initially, the capability was limited to linking documents within a 
single computer. The functionality was extended to allow one to select documents (or 
pages) on other computers at different sites on the Internet. The hypertext transfer 
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protocol (HTTP) was the protocol developed to provide this “remote” capability. 
HyperText Markup Language (HTML) is the file standard used in developing the 
hypertext documents or pages. It defines the “codes” necessary to create hypertext links 
as well as codes to enhance the presentation of a page. HTML documents can be very 
dynamic, often containing audio, video, and animation. 

Web technology has two main components: a server (HTTP server) and a client 
(or web browser). The HTTP server (more often referred to as a Web server) serves or 
transfers an HTML document to the web browser. The web browser interprets the HTML 
document and displays it to the screen. The process is as follows: 

• Your browser reads a document written in HTML and displays it for you, 
interpreting all the markup codes in the document. 

• When you click on a hypertext link (hyperlink) in that document, your 
browser uses HTTP to send a network request to a Web server to access the 
new document or service specified by the hyperlink. 

• Also using the HTTP protocol, the Web server responds to the request with 
the document or other data your requested. 

• Your browser software then reads and interprets that information and presents 
it to you in the correct format. (Evans, 1 996) 

In summary, an intranet is a TCP/IP network which is internal to your 
organization, containing HTTP servers that provide HTML documents and other services 
to Web browsers (e.g., Netscape’s Navigator or Microsoft’s Internet Explorer) running on 
various hardware platforms throughout the network. 

B. INTRANET BENEFITS 

This section outlines the more prevalent benefits that result from instituting an 
intranet. This list is not confined to NPS, but focuses on how organizations in general 
can benefit from this technology. Other benefits may be realized because of the particular 
nature of an organization’s business, information, and communication requirements; the 
size of the organization; and the geographical locations of its components. These various 
aspects may align well with the intranet concepts and then allow for greater benefits. 
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1. Low Implementation Costs 



Web technology is based on mature and “truly open standards such as TCP/IP, 
HTTP, HTML, CGI, and Java, and thus does not lock organizations into proprietary 
technology with limitations and significant costs.” (Linthicum, DBMS 1997) The 
hardware and software components necessary to get an intranet up and running are cheap. 
Often, most of these components are already in place. For example, most organizations 
have some sort of proprietary network already running, and adding TCP/IP to these 
networks is usually a simple task. Moreover, most network operating systems today are 
shipped with their own TCP/IP stack, eliminating some of the cost for an intranet. In 
addition, many PCs today come with a Web browser already loaded. Even if these 
components had to be purchased, they are relatively inexpensive. 

Furthermore, “Web applications driven from a single browser require less 
training, and deployment costs are reduced due to the single interface, protocol, and 
middleware architecture. Large organizations report costs of less than $40 per user to 
create and intranet infrastructure, compared to approximately $2000 per user for 
traditional two-tier client-server application infrastructure.” (Linthicum, DBMS 1997) 

2. Universal Client 

Another benefit of intranets is the multi-platform nature of Web browsers. 
Browsers exist for most operating systems that are windows-based or that provide some 
sort of graphical user interface (GUI). These include UNIX (X-Windows), Microsoft 
Windows (3.1 1, 95, and NT), Macintosh, and OS/2. The availability of browsers across 
these diverse platforms is significant. The operating environments of the author, Web 
and applications servers, and the client viewer are independent of each other. Any 
document adhering to HTML and the related standards which is served by an HTTP 
server can be accessed by any client regardless of the operating environment from which 
they originated. (Telleen, 1996) 

The ubiquity of the browser, therefore, brings two obvious benefits. The first is 
that the user only needs to learn one interface, allowing the user the opportunity to 
become proficient with the one interface. Also, this allows training and support costs to 
be focused in one direction, and should result in a lower costs overall. 

The second benefit deals with classic client-server application deployment issues. 
One of the most costly aspects of client-server development in a multiplatform 
environment is developing and maintaining a separate client interface for each platform. 
This benefit of Web browsers is important to the concept of “thin-client” architecture. In 
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intranet-based applications, the application logic is located either on a Web server or an 
application server. Therefore, changes to the application can be made centrally, without 
the need to update and re-deploy the client, which would require considerable time and 
cost in a mulitplatform environment. 

3. Simple and Intuitive Interface 

The Web browsers use of point-and-click hyperlinking technology allows users to 
navigate and locate information easily. This type of interface is very intuitive and easy to 
learn. Furthermore, since the users are using one interface to access information and 
applications, they can quickly become proficient with the Web pages and Web 
applications. 

4. Information Access 

The Web information publishing paradigm has two primary advantages. The first 
advantage deals with the “push-vs.-pull” information distribution debate. In the “push” 
mode, “all” information is sent to the user, and the user must decide whether to read or 
discard the information. In the “pull” mode, users only pull what they need. The “pull” 
mode allows a person to be more efficient and selective in what they process, instead of 
wasting their time sifting through hoards of mostly non-essential information. The Web 
is well-suited for this. Information providers can publish the information and place it on 
a Web server. Users that want to access the information, have the choice to “pull” it 
down if they decide it is essential to their needs, or choose to ignore it if it is not essential 
to their needs. 

The second advantage rises from the simplicity in updating Web content. For 
example, in the past, organizations published employee handbooks once a year and 
distributed them to all employees. Traditionally, even though these handbooks may have 
been out of date the day they were distributed, they would not be updated until the 
following year. With an intranet publishing strategy, information can be updated 
instantly, and there is no need for reprinting, duplicating, and distributing reams of ink 
and paper. Duplication and distribution are achieved by simply placing the handbook on 
a Web server. In support of this intranet benefit, “a recent International Data Corp. (IDC) 
study pegged ROI (return on investment) at 1 ,000 percent or better — mostly in paper and 
labor costs.” (Currid, 1 997) 
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5. Multimedia Content 



Besides the quick and easy access to timely information, the information itself can 
be in a variety of formats, including text, graphics, video, audio, and animation. This can 
enhance the exchange of information and allow for different types of information to be 
conveyed. Web browsers already provide capabilities for these various formats, and 
therefore intranets provide this benefit at no extra cost. 

C. INTRANET CONSIDERATIONS 

Intranets are not the panacea for all computing and information needs of an 
organization. The benefits discussed above do not come f ree without certain 
considerations. Three main considerations are explored below: 

1. Ease of Use 

Though “ease of use” is a benefit of Web publishing on intranets, it also can 
become a negative attribute. For example, it is easy for any person in an organization to 
start putting content out on the internal Web. If not managed in some way, issues of 
information glut, security, privacy, and performance may become significant, resulting in 
more problems and a negative ROI. Therefore, much consideration into how the 
information infrastructure is to be managed must be put forth before the intranet takes off. 
How to manage the content producing infrastructure in an intranet is a topic of great 
debate and is beyond the scope of this thesis. In short, the debate centers around 
centralized or decentralized control of content production. If control is decentralized, 
how does one ensure the content developed adds value to the organization, or at a 
minimum, does not detract from the mission? On the other hand, if control is centralized, 
is the effectiveness and creativity of the organization greatly limited? Most successful 
intranets seem to find a balance between the two approaches to content management. 

2. Security 

The “ease of use” issue also highlights the need for security. If information is 
easily accessible, then extra care must be taken that only authorized users are allowed 
access to certain pieces of information. Most organizations have Internet access, and 
therefore a potential hole into the intranet exists via this Internet connection. Firewalls 
are special workstations that control access between your intranet and the Internet. Great 
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care must be taken in the administration of firewalls and other security measures because 
of the speed with which information can flow through an intranet and out to the Internet. 
For example, if an administrator incorrectly sets permissions on a document outlying 
future strategies of a corporation that only the executive staff is supposed to see, and the 
whole Internet has access to it, competitors may view it and restructure their business 
accordingly. 

3. Interactive Application Development 

The traditional Web technology was never designed to support interactive 
applications. HTTP and HTML form a “request-download-view-disconnect” type of 
architecture and cannot process applications interactively. (Linthicum, DBMS 1997) 

Interactive applications require persistent connections between client and server. 
HTTP makes a connection, downloads a document, and then closes the connection. It has 
no mechanism to maintain a persistent connection. Furthermore, the original Web 
architecture could only deliver static content. Web pages had to be prepared beforehand, 
and placed on the web server for delivery. No mechanism existed to deliver dynamic 
content. In other words, there was no way to create pages on-the-fly. This capability is 
necessary for interactive application development. 

D. WEB APPLICATION ARCHITECTURE 

Originally, as stated above, the Web could only publish or present static content. 
With the introduction of CGI (common gateway interface), a Web server could then 
deliver dynamic content back to the user’s Web browser. CGI is a protocol that defines 
how an external process on a Web server can create dynamic Web pages. CGI programs 
work in the following manner: The Web server runs the CGI program on behalf of a 
user, the CGI program does some processing, creates an output HTML document, and 
then stores it in an agreed upon filename or memory location. When the CGI program 
exits, the Web server delivers the document back to the client Web browser. The CGI 
program may do calculations based on input from the user, or it may access a database 
and create a document with the requested information. The CGI program can be written 
in any language supported by the Web server’s operating system. For example, the NPS 
Locator Web server (WebSite 1.1) runs on Windows NT; therefore, any programming 
language supported by Windows NT can be used for CGI programs. Some common 
languages may include Visual Basic, C++, Powerbuilder, Java, and Delphi. 
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One drawback of a traditional CGI executables is their inefficiency when 
connecting to a database. Each time a user requests a dynamic page of data, the Web 
server creates a new CGI process, connects to the data source, receives the data, closes 
the connection and shuts down the CGI process. The larger the CGI program, the more 
overhead is created on the Web server, resulting in slower performance. In addition, 
much overhead is incurred from opening and closing a database connection. 

To address some of the inefficiencies of CGI, most Web server vendors provide 
an application programming interface (API), which allows direct access to server-side 
applications that run as part of the Web server. “In most cases this leads to faster and 
more compact memory-wise equivalents to CGI programs, though no longer portable.” 
(Kohlhepp, 1997) “Functions written to a server’s APIs can be multithreaded, therefore, 
one process can service multiple requests, keeping the memory requirement down.” 
(Kohlhepp, 1997) CGI, on the other hand, must start a new process for each request. 

Though APIs can have better performance than CGI, APIs can crash a web server 
because of the shared web server memory space. CGI extensions are separate programs 
that cannot affect the operation of the web server itself. Web applications that use the 
API extensions approach are much more complex and demand advanced programming 
skills such as “multithreading and concurrency synchronization, network protocol 
programming and structured exception handling.” (Denny, 1996) 

It is important to note that both approaches provide the same functionality within 
the application architecture, the only difference being the issue of performance. Both 
approaches still require opening and closing of data connections. 

Furthermore, both methods fail in the area of state management. HTTP is a 
stateless protocol. Each browser request is distinct, and in its raw form, completely 
disassociated from any prior request. This works well for static HTML pages, but does 
not work in a database application for transaction management or navigation. The server 
needs to know who performed what operation in order to commit a transaction, or needs 
to know what record the user is on to know which record is the next one. By the nature 
of the Web, there is never a constant connection to the Web server, so this information is 
not retained. (Krull, 1997) 
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Many vendors have developed an architecture to solve the issues of CGI 
performance, persistent data connections and state management. This architecture, as 
seen in Figure 1 , has four main components: a courier module, a broker, an application 
agent, and a database. This architecture is based on the architectures from Borland, 
NetDynamics, and HREF Systems. The architecture has been generalized and some of 
the component names changed to simplify the discussion. 

Application requests flow through the architecture in the following manner: 

1 . The Web server passes a browser’s HTTP request to the broker module 




through a courier, which is either a lightweight CGI “stub” (15-50kb for most 
implementations), or a Web Server API-based (NS API or IS API) dynamic 
link library (DLL). 

2. The broker receives the request from the courier and then passes it to the 
appropriate application agent. The broker is responsible for assigning a 
unique session ID to new clients so that user “state” can be maintained across 
multiple requests from the same user. This ID is included in every HTML 
page generated, so that when the user makes a subsequent request, they will 
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pass back the session ID with their request, allowing the Application Agent to 
track the user. 

3. The Application Agent then processes the request by accessing a database and 
applying any necessary business logic. The Application Agent then creates 
the output HTML document and passes it back to the Web server and the 
Courier module shuts down, signaling the Web server to deliver the document. 

In this architecture, the Application Agents stay loaded and can maintain data 
connections, eliminating the performance problem with traditional CGI architecture. In 
addition, the reduced size of the CGI program also saves in resources and performance. 
In this architecture, the CGI is used merely to pass information to the backend system and 
to signal when the HTML document is ready for transmission back to the user. 

Most vendors allow there to be more than one instance of an Application Agent to 
be running at a time. The Broker is responsible for load-balancing requests across the 
Agents. In addition, most systems allow the Agents to be located on different 
workstations, therefore allowing for scalability of the system by adding additional remote 
servers as seen in the architecture diagram. 
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III. NPS LOCATOR DEVELOPMENT 



A. REQUIREMENTS 

In developing the NPS Locator Prototype, one guiding principle existed: The 
prototype should require minimal changes to the NPS computing environment. The 
computing environment refers to the data sources, network infrastructure, and client 
machines. The reason for this requirement was to eliminate any barriers, political or 
technical, to implementing the system. Then, after the prototype has been implemented 
and has proved its value, requests for changes to the environment may be made. 

The remaining portion of this section presents the requirements defined for the 
design and functionality of the NPS Locator prototype. These requirements are limited in 
scope because of the prototype nature of the Locator and do not represent the “ideal” 
directory system. 

1. Functional Requirements 

• The system must provide a means for NPS personnel to obtain communication 
and location information on any other person at NPS. This information 
includes email address, phone and fax numbers, building and office locations, 
homepage URLs, mail codes, position title, and a picture. Any information 
that aids, either directly or indirectly, the location of or eventual 
communication with a particular individual should be included. 

• The system must provide search capabilities to locate personnel by last name, 
department, and status (i.e., student, staff, or faculty). The last name search 
should provide partial name searches in which the user is only required to 
input the first few letters of the last name. 

• The system should allow users to augment their locator listing with 
information they provide through the system. Users should be provided with 
the option of providing other information that enables communication with 
that user. For example, users may want to input their home phone and mailing 
address, or they may want to provide a time schedule of when they are 
available for phone calls and appointments. 

• The system should maximize the use of built-in communication facilities. For 
example, if using web browser technology, email addresses should be 
presented as a hypertext link that when selected will call up the browser’s 
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built-in mail tool. Also, hyperlinks should be used when possible to link to 
additional information or resources. 

• The locator should maximize automatic methods of updating the locator data 
stores, and minimize human intervention. Manual updates often do not get 
done on a regular basis because they can be very tedious. Automatic updates 
are easily run on a much more frequent basis, which results in more current 
data. 

2. System Requirements 

• The NPS Locator should be accessible from multiple platforms to include 
UNIX workstations, PCs, and Macintosh computers. 

• The system should require little or no additional software on the client 
machines except for a web browser. 

• The system should be accessible from any network that supports TCP/IP and 
HTTP. NPS currently has four major network operating systems (NOS) 
installed: UNIX TCP/IP, Banyan Vines, Novell NetWare, and AppleTalk. 
Currently, all these NOS support TCP/IP. 

• The NPS Locator should be developed with standard tools that are familiar to 
the NPS computing support staff. These tools include primarily Borland 
Delphi and Oracle development products. 

3. Data Requirements 

The data sources for the NPS Locator should be from the data owners to ensure 
that the most accurate and current information is used. The Locator should either directly 
access the original data for its queries, or it should build its own data store from the 
original data. If building its own data store, then the frequency of the updates must be set 
such that the updates capture most of the changes to the original source. 

B. DEVELOPMENT TOOLS 

The tools selected for the prototype development were, for the most part, dictated 
by their familiarity within the NPS computing support staff. The tools, therefore, may 
not represent the “best” tools for the job, but did allow for a short development time, 
which is in line with the prototype concept. 
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1. Programming Tools 



The most significant tool to the prototype development was WebHub from HREF 
Systems. “WebHub is a CGI framework for building dynamic, database-driven web sites 
with Delphi for deployment on Windows-based web servers.” (HREF, 1996) “A 
Framework is a set of prefabricated software building blocks that programmers can use, 
extend, or customize for specific computing solutions.” (Taligent, 1997) Frameworks 
prevent a software developer from having to start from scratch each time he writes an 
application. WebHub’s framework includes “over 30 web-specific Delphi components” 
for building custom made web applications. WebHub uses the Web “broker-agent” 
architecture discussed above. 

Accordingly, Delphi was used in conjunction with WebHub to add the business 
logic specific to the NPS Locator application. Delphi also was used to build programs 
that populate the Locator’s database. These Delphi programs collect data from various 
data sources throughout the NPS infrastructure, normalize it, and then store the data in the 
database. 

Perl allowed data aggregation from UNIX platforms. Perl stands for Practical 
Extraction and Report Language. It is ideal for extracting data from UNIX file systems 
and then formatting that data into specific output files. 

2. Web Server 

O’Reilly’s WebSite Web Server was chosen to host the NPS Locator prototype 
because of its wide use at the school. WebSite can run on Intel platforms using either 
Windows 95 or Windows NT. The WebSite-Windows NT combination served as the 
NPS Locator Web platform. 

3. Database Server 

Finally, the NPS Locator database was tested on two platforms. The first was on 
an Oracle 7.2 database server. The database server platform was a DEC Alpha 
workstation running an Alpha version of Windows NT. Once again, the selection of this 
component resulted from its availability and familiarity at NPS. Some expertise existed 
with the Oracle server because it was used as a test bed for possible migration from the 
mainframe database to a client-server workstation environment. The second test was run 
with a local Paradox database resident on the Web server machine. Both test were 
successful and provided acceptable results. 
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C. NPS LOCATOR ARCHITECTURE 



The NPS Locator has two main components: the NPS Locator Web Application 
and the Locator Update component. The Web Application provides the user interface, 
business logic, and data representation. The Update component gathers data from a 
variety of data sources, parses that data, normalizes it, and then stores it in the Locator 
database. This section will first discuss the Update component and then follow with an 
explanation of the Web Application. 

1. Update Component 

The Update component is a collection of data sources, automated data-extraction 
scripts, and file-transfer routines. These various components can be seen in Figure 2 
below. 




Figure 2. Update Component Architecture 



The Update component can be broken down into three phases. Phase I consists of 
the extraction of student data from the Curricular Database, extraction of email and 
homepage URL information from the Computer Center (CC) UNIX accounts, and 
extraction of staff and faculty information from the Staff/Faculty Database. Phase II 



20 



consists of “harvesting” the extracts created in Phase I, and storing them on the Web 
Server. Phase III merges the extracts and then stores them in the Locator’s Oracle 
Database Server. Before discussing the three phases, an explanation is provided of how 
the data sources were selected for the prototype and what information they provide. 

a. Data Sources 

One of the goals of the prototype is to eliminate, or at least minimize, the 
duplication of effort in creating and maintaining data sources. This is accomplished by 
using the data sources of the data owners. A “data owner” is, for the purposes of this 
thesis, a person or organizational body that is responsible for the creation and 
maintenance of particular data, usually relevant to their organizational function. For 
example, the Registrar is the “data owner” of all information pertaining to grades and 
class schedules. The Registrar creates and maintains a “Registrar Database” that contains 
data that pertains to grades and class schedules. Therefore, one would expect that the best 
source (i.e., the most accurate and up-to-date) for such information would be the 
Registrar Database. 

Using data ownership as the primary criterion in selecting data sources, the 
Curricular Officer’s Database was selected as the data source for students’ personal 
information and the CC UNIX user accounts were selected as the data source for email 
and homepage URL information. The information extracted from the Curricular 
Database is as follows: SSN, name, grade, service, student mailbox number, department, 
curriculum, section, entry date, and graduation date. 

The CC UNIX password file and file system serve as the second data 
source used by the Update component. A sample line entry in a UNIX password file is 
shown below: 

jeforte:67kBjs/mctYuc:24865:20: Jeffrey E. Forte, 25 13 :/h/ joshua_u2/ jeforte:/bin/csh 

Each field in the password file is separated by a colon The fields 

are: 

• username, which also serves as the email address (“jeforte”) 

• password, which is the user’s encrypted password 

• userid, which is the unique (to the UNIX system) numerical ID that represents 
this user 

• groupid, which is the ID of the group to which this user belongs 
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• quota and comment, which represent different things on different machines 

• infofield, which is a character string containing personal information about the 
user. In the case of CC accounts, it contains the user’s full name, followed by 
a comma, and a unique four digit number used by the administrator to track 
the user. 

• homedir, which is the user’s home directory 

• shell, which is the command shell that is started when the user logs in 

The information extracted from the password file includes last name, first 
name, middle initial, email address, and home directory. The home directory is extracted 
in order to determine if a user has a homepage. If a user of the CC UNIX system wants 
to have a homepage, the user is required to create a directory called “publichtml” under 
his or her home directory, and place the page in this directory. The file must be named 
“Welcome.html” or “Index.html.” By searching the home directory, it can be determined 
if the user has a homepage by searching the user’s home directory. 

The final data source used is a staff and faculty database that was created 
for use by the prototype. It was difficult to find good data sources for staff and faculty 
information, and the ones that did exist, were not readily available because of 
bureaucratic reasons. Again, since the staff and faculty data is relatively static compared 
to the student data, for the purpose of the prototype this database was sufficient. The 
proof in concept can be demonstrated on the more dynamic student data. 

b. Phase I 

In Phase I, automated scripts extract information from the data sources 
discussed above, and then store the data as ASCII flat-files on the respective systems in 
accounts set aside for the Locator system. Refer to Figure 2. Starting from the left, the 
first data extraction routine encountered is the “FOCUS Extract” program. This program 
was written for the prototype by Judy Harr, a FOCUS database administrator. It extracts 
student information from the Curricular Officer’s Database, formats it into an ASCII flat- 
file, and stores it in a special mainframe account set aside for the Locator prototype. The 
frequency of this process is adjustable, and was set to process once a day, early in the 
morning when processing levels are low. 

The second data extraction routine consists of a Perl program residing on 
CC UNIX system. This program parses the password file, and pulls out each username 
(email address), the user’s full name, and his or her home directory. When it gets the 
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home directory, it checks to see if a “public_html” directory exists. If so, it then looks for 
a filename of either “Welcome.html” or “Index.html.” At this point it writes out to an 
ASCII flat-file with the following format: last name, first name, middle initial, last name 
with initials appended, homepage URL (if one exists), and username. The text below 
shows two entries in the resulting file: 

FORTE JEFFREY E. FORTEJE http://vislab-www.nps.navy.mil/~jeforte jeforte 
EMERY JAMES C. EMERYJC jcemery 

The Perl program is executed once a day early in the morning. This is 
accomplished with the UNIX “cron” command, which executes commands at specified 
dates and times. 

The third routine would be the extraction of staff and faculty information 
from the staff and faculty database. Since this database was created for the prototype 
specifically, it is conveniently located on the Web server ready for the Phase III process, 
and therefore no real extraction is taking place. If this database did not exist, the third 
data extraction routine would probably pull information from the Human Resources 
database as well as other pertinent sources of staff and faculty information. This 
simulated third routine concludes Phase I. 

c. Phase II 

Phase II can be considered the “harvesting” phase. In this phase, all of the 
extraction files are retrieved from their originating locations and stored on the Locator 
Platform (Windows NT server) in preparation for Phase III. Appropriately, Phase II is 
accomplished by a program written in Delphi named “Harvest.exe.” This program uses 
an FTP component from Netmanage Corporation. FTP is a file transfer protocol that 
works on top of TCP/IP. It is useful in transferring files across a TCP/IP network, such 
as the NPS Intranet. The Harvest program, which is resident on the Locator Windows 
NT Server, initiates file transfers with the Locator account on the CC UNIX system to 
retrieve the email/homepage ASCII flat-file, and with the Locator account on the 
mainframe to retrieve the Curricular Database extract. The Harvest program is setup as a 
Windows NT service, which allows it to be scheduled to execute at predetermined times. 
In this case, it is scheduled to run everyday, approximately two hours after the extraction 
scripts execute. Once the files are residing on the Locator platform, Phase II has 
successfully completed. At this point, the completion of the Harvest program triggers 
Phase III. 
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d. Phase III 



Phase III of the Update component takes the ASCII flat-files and the 
Staff/Faculty database and merges them together, and then stores the resulting data in the 
Locator Oracle database. The “Merge.exe” program, which is triggered by the 
completion of the Harvest program, is the workhorse of the third phase. The Merge 
program also was created using Delphi. The Delphi TBatchMove component is used to 
convert the ASCII files into the standard DBF format that Delphi supports. This 
component also ensures no duplicate index keys get added to the resulting database. The 
Merge program uses this function with the last-name, first-name, middle-initial 
combination to eliminate duplicate records for all personnel. Then each of the converted 
databases is cleaned and standardized. For example, the Curricular database file was 
inconsistent on how it handled two-part last names such as Van Horn and Van 
Steenberger. In one case, the two parts are appended, as in Vansteenberger. In the other 
case, the two are separated by a space, as in Van Horn. This inconsistency makes it 
difficult to merge the UNIX extract file with the Curricular extract file because in the 
UNIX file Vansteenberger is Van Steenberger. It is unfortunate that names had to be 
used as the index key for the merge, but the UNIX accounts do not record any part of the 
SSN or other usable unique identifier. Moreover, the Curricular database does not store 
separately the last name, first name, and middle initial of a student. They all are 
combined in a single field labeled “name.” As a result, the Merge program does a “best 
effort” in correlating data from the various data sources using the components of a 
person’s name. For the most part, it is successful. 

After cleaning the data, the Merge program uses an SQL “Insert” query to 
update the Locator’s Oracle database resident on a DEC Alpha. In essence, the Locator’s 
main table is recreated every morning. Following the rebuild of the main table, another 
query is executed that links records in the main table with the “register” table which 
stores information on users who have registered with the Locator Application. In short, 
the register table stores the login, password, and other information with which the user 
chose to augment his listing. At this point, the Merge program exits, and the Update 
component has completed its function. 
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2. NPS Locator Application 



The Locator Web application architecture can be seen in Figure 3. The 
application, as discussed earlier, uses WebHub, and therefore utilizes the broker/agent 
architecture. The application resides on a Windows NT Server. The main components 
on the NT Server include WebSite Web Server, WebHub, and NPSD.exe (Customized 
WebHub WebApp). The business logic and Locator functionality are coded into the 
NPSD.exe Delphi program. It was developed using the WebHub Web Application 
framework. 




Figure 3. NPS Locator Architecture 



The other major component is the data store for the Locator data. The data resides 
on a DEC Alpha workstation running Oracle 7.2 Database Server, with two main tables, 
one labeled “main” and the other labeled “register.” The structure of these tables can be 
viewed in Appendix A. The Locator NT Server communicates with the Oracle Server via 
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the TCP/IP NPS Intranet. More specifically, the NPSD program uses Borland’s SQL 
Links to communicate with the Oracle database. SQL Links in conjunction with Oracle 
drivers allows full connectivity to the Oracle Database Server from any Delphi program 
utilizing Borland’s Database Engine (BDE). 

D. FUNCTIONAL DESCRIPTION 

This section describes the functional operation and capabilities of the NPS 
Locator prototype. When possible, various screen-shots of the prototype will be 
presented to aid in the description of whatever aspect is being discussed at the time. The 
first screen-shot is shown below in Figure 4. It is the main page of the Locator. The 
options available to the user at this point are “search,” “login,” and “register.” Each will 
be discussed below. 



1. Search 



The search feature represents the real purpose of the directory system. The 
Locator provides a basic search capability. The user can search for a person in a few 
different ways, usually depending on how much information the user already has about 
the person he is looking for. 
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Figure 5 shows the search page for the Locator. The user has the option to use a 
“first letter” search by selecting the appropriate hyperlinked letter in the displayed 
alphabet. This will generate a query to the Locator database, which will return all 
personnel with a last name starting with the selected letter. The user then can scroll 
through the records to find the name he was looking for. 
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Figure 5. Search Screen 



For a more narrow search, the user can type in all or part of the last name in the 
appropriate block in the Advanced search dialogue. The search is not case-sensitive. The 
user can further narrow the search by entering in a department code and/or the employee 
type. The available employee types are faculty, staff, and student. The department code 
should later be implemented as a selection box, so that users can select the department 
code without confusion of what should be entered, and to prevent spelling errors. 

Once a user a has initiated a search, the Locator will respond with the search 
results in a table format as shown in Figure 6. The information includes last name, first 
name, middle initial, title, department, mail code, phone and fax number, email, and a 
homepage link. If the person has an email account at the computer center, then his or her 
email will show up in the column, and it will be hyperlinked. The hyperlinked email 
will, when selected, bring up the user’s mail program with the “to:” block filled in with 
the email address selected from the Locator. If a person has a homepage at the computer 
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center, then his or her homepage URL will be listed under the “Homepage” column and 
will be hyperlinked. 

The last name column is hyperlinked also. When it is selected, it displays a page 
that provides more detailed information on the particular person. If the person has 
registered with the Locator, then there may be additional information including a picture, 
if the person chose to provide it. Figure 7 shows what the detail page looks like. 



2. Register 



NPS personnel can “register” with the Locator by clicking on the “register” link 
on the home page. This then prompts the user to enter his last name so the Locator can 
display his record. Once the appropriate record is found, the user selects his record by 
clicking on the hyperlinked last name. This then prompts the user to enter in an email 
address, which will serve as their login name. The email address is also used by the 
Locator to automatically send the user a system-generated password, which, when used in 
conjunction with the login, allows entry into the Locator. 
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If a user is not in the system, the user is incorrectly listed in his or her respective 
data source. For example, a student not listed in the Locator database, in most cases, is 
not listed in the Curricular Officer’s Database. The appropriate action by the user would 
be to contact his Curricular Office and verify that he is listed correctly in the database. 



3. Login 



Once a user is registered, he has the ability to augment the system generated 
information. For the prototype system, a user can upload a picture, and add one 
additional email address and an additional URL, both of which will be hyperlinked. 
Finally, the user can add information in a text box, up to 256 characters. This block 
should be used for information that enables communication with the listed person. For 
example, a professor may place his class schedule and available officer hours in this 
block. A staff person may put in the days that he or she plans to take leave. As a final 
example, a student may put in his thesis study area so that others may locate him. 
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IV. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The NPS Locator provides a simple, interactive, and easy-to-use facility for users 
to access useful information about other NPS personnel. The Locator successfully ran for 
two months during a test in the NPS computing environment. Updates from the 
Curricular Officers’ database and from the CC UNIX accounts were successfully merged 
and uploaded to the Locator database. This database provided an accurate and up-to-date 
resource of personnel information that enabled the communication and location of NPS 
personnel. In addition, the Locator allowed a user to augment his or her system generated 
information with additional information to further enable communications between 
individuals. 

The implementation of the Locator prototype did not unveil any new revelations 
for those in charge of computing at NPS, but did re-emphasize some of the current issues 
NPS is struggling with, as well as reinforce the benefits of Intranet technology. The 
explosive growth of Web technology and intranet implementations in the Corporate 
world can serve as a testimonial for the potential of intranets. 

The benefits that NPS can obtain from intranet technology are as follows: 

• The Web browser is a universal interface that allows interoperability in NPS’s 
multiplatform and multi-NOS environment. 

• The thin-client architecture of intranet applications allows NPS to use fewer 
application development tools and eliminates costly multiplatform 
deployment of applications. 

• Intranets provide a fast and ubiquitous information distribution platform that 
faculty, staff, and students can use. 

• The intranet’s ease of updates fosters the publishing of information that is 
more accurate and up-to-date. 

• Intranet technology is relatively cheap which is important in the times of 
budgetary constraints. 

Perhaps the real value of the implementation of the NPS Locator prototype lies in 
its emphasis of issues plaguing the application of information technology at NPS. For 
example, an NPS Phone Book application was developed recently, and is appropriately 
available on the NPS homepage. The directory is complete and is easy to use. Its data 
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source is a centralized SQL database maintained by code 05. Despite its accuracy and 
timeliness, many organizational units still have their own Web directory on their 
organizational homepage. The information in these directories is not maintained in synch 
with the Code 05 database. This duplication of effort and lack of some centralized 
management will hinder the success of an effective intranet implementation at NPS. 

B. RECOMMENDATIONS 

In order to implement any directory system or other intranet application at NPS, 
many issues must be dealt with. Some of the issues outlined below are indeed addressed 
in the recently published 1997 draft of the “Strategic Plan for Computing at the Naval 
Postgraduate School.” The issues to be explored are: 

• There is a need for a centralized personnel database that contains all NPS 
personnel. Code 05 has developed and maintains a centralized personnel 
database that currently supports the new accounting system and the NPS 
Phonebook. The database should further be integrated into other systems as 
the sole source for personnel information. Policy should be enacted 
mandating the use of this database as the source for all personnel information 
and that it be properly maintained as such. 

• All NPS personnel should have an account or alias at the NPS Computer 
Center. This provides a guaranteed uniform email address for all personnel at 
NPS. This coupled with a naming standard will make email addresses 
derivable just by knowing a person’s name. For example, if the standard is a 
concatenation of the first initial, middle initial, and the first six characters of 
one’s last name, and given that the domain for NPS is nps.navy.mil then 
deriving an individual’s full email address is simple. Jeffrey E. Forte would 
be jeforte@nps.navy.mil. 

• All organizational entities should have an organizational mailbox. An 
organizational mailbox is not associated with any one person within an 
organization. It allows communication with the organization without having 
to know someone within that organization, and it serves well as a method for 
passing official messages. Organizational mailboxes may be best 
implemented as hotlinks on an organizational chart. 

• Support should be demanded for centralized management of the computing 
infrastructure that is balanced with distributed control within organizational 
units. The Provost of Computing needs to have support from the highest 
authority at NPS, and a method for enforcing adherence to standards. The 
right balance between centralized and decentralized control and areas of 
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responsibilities needs to be explored to maximize the effectiveness of intranet 
implementation. 



• An NPS data dictionary should be developed for all informational entities and 
attributes. Sometimes it is not practical to use one centralized database for all 
applications because of performance issues, security restrictions, or 
communication limitations. It would be advantageous to record all 
information, despite how it is used, in a uniform and predictable manner. For 
example, many of the databases reviewed as potential databases for the 
Locator stored the elements of a person’s name in very different ways. The 
Curricular database stored the name as one field, separating the last name and 
first name by a comma. Other databases had the usual breakout of the name 
into its three components — first, middle, and last names. The use of a data 
dictionary allows for any possible future exchanges of information with any 
information store to be compatible with respect to the format of the individual 
data elements. 

• Consideration should be given to the creation of a unique identifier for each 
person at NPS. This would allow the use of this id as a unique index key to 
individuals without the possibility of compromising privacy by use of the 
social security number. Furthermore, any time information is recorded on an 
individual, password files included, this unique id should be recorded as well. 

• NPS should conduct a survey of commercial directory systems for NPS use. 
Many vendors are offering directory systems that allow customization, and 
most of them provide a single login and password for access to all network 
resources from anywhere on the network. Banyan’s StreetTalk for NT and 
Novell’s NDS for NT are two popular offerings. 

Any tool is effective only if used appropriately. Intranets are no exception. 
Technology is only half of the solution; management is the other half. If a synergy exist 
between these two elements, an intranet can help harness the potential of an organizations 
information technology. 
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APPENDIX A. DATABASE TABLES 






MAIN 


1 


REGISTER 1 


ID 1 


JL 


ID 


LAST 


i 


FKID 


FIRST 




EMAIL2 


MIDDLE 


- * - * 


URL2 


STATUS 




PHONE2 


TITLE 


•s 


FAX2 


DEPT 




COMMENTS 


LOCATION 




ACTIVATED 


MAILCODE 




EXP 


PHONE 




PASSWORD 


FAX 


' 


PICTURE 


EMAIL 






URL 


- 




REGISTERED 








2 


- 
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APPENDIX B. UPDATE COMPONENT PROGRAMS 



This Appendix contains the Perl script, the Harvest source (ftph.pas) and the Merge 
source (merge 1. pas) used in the Update Component of the NPS Locator Prototype. 



#! / l oca l /bin/ per l 
# 



# Go through every users passwd entry and see if they have a public_html 

# directory. 

# 

# 

# 

U push(3INC, '/local/lib/perl 1 ); 



# Open the output file for writing 
open(UserList,">userlist .txt"); 
open(NoShow, ">noshow. txt"); 

# 

# See who's got web pages 

# 



whi le(($name f Spwd, Suid, Sgid, Squota, Scomment, $gcos # $home_dir, Sshell) 
= getpwentO) 






SFirstName = 
SMiddle = «"; 

SLastName = 
SNameParts = (); 
SNumParts = 0; 
SldCheckl = 
$IdCheck2 = »»; 
SLastFiMi = "«; 



(SFullName, Sacctno) = split(/, /,$gcos,2); 

#(SFirstNanne, SMiddle, SPrefix, SLastName) = spl i t (/ /,SFul IName); 

#(SFi rstName, SMiddle, SLastName) = spl i t (/ /,SFul IName) unless SLastName; 

#(SFi rstName, SLastName) = spl i t (/ /, SFullName) unless SLastName; 

#Should add test for names with suffixes like "MI" or "Jr" 

SNameParts = spl i t (/ /,SFul IName) ; 

SNumParts = SNameParts; 
if (SNumParts == 1 ) C 

SLastName = SNameParts [0] ; 

SldCheckl = SLastName; 

>elsi f (SNumParts == 2) { 

SFirstName = SNameParts [0] ; 

SLastName = SNameParts [1 3 ; 

SldCheckl = SLastName; 

}elsif (SNumParts == 3) C 

# ****** USE PATTERN MATCHING TECHNIQUES HERE ! M !!!!!! M M M ! Also need to look at III/jr./sr./ 

if ((SNameParts [1] eq "Van") or (SNameParts [1] eq "Al") or (SNameParts [1) eq 

"Von")K 

SFirstName = SNameParts [0] ; 

SLastName = SNameParts [1] . " " . SNameParts [2] ; 

SldCheckl = SNameParts [23 ; 

}else{ 

SFirstName = SNameParts [03 ; 

SMiddle = SNameParts [13 ; 

SLastName = SNameParts [23 ; 

SldCheckl = SLastName; 

> 

>elsif (SNumParts == 4) t 

if ((SNameParts [23 eq "Van") or (SNameParts [23 eq "Al") or (SNameParts [23 eq 

"Von"))C 
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SFirstName = SNameParts [0] ; 

SMiddle = SNameParts [1] ; 

SLastName = SNameParts [2] . " " . SNameParts [3] ; 

SldCheckl = SNameParts [3] ; 

>elseC 

SFirstName = SNameParts [0] ; 

SMiddle = SNameParts [1] ; 

SLastName = SNameParts [3] ; 

SldCheckl = SLastName; 

> 

}else C 

SLastName = "Error !! --" . SFullName; 

> 

SLastFiMi = SLastName . substr(SFirstName,0,1 ) . substr(SMiddle,0, 1 ); 

# print "Lastname = $LastName\n" if Sverbose; 

# 

# Look for welcoming file 

# 

SURL = 

if (-d "Shome__dir/public html") 

C 

Sroot = "$home_di r/publ ic_html/"; 

Sf = 

aWList = ( 

"Welcome.html", 

"welcome. html", 

"Welcome.htm", 

"welcome. htm", 

"index.html", 

"index.htm", 

mi 

i 

); 

foreach $w OWList) t 
Sf = Sw; 

last if -e Sroot. Sw; 

> 

if (Sf) i 

SURL = "http://vislab-www.nps.navy.mi l /■'Sname"; 

> 

else C 

SURL = 

> 

> 

if ((SLastName ne "User") or (SFirstName ne "")K 

SF3 = substr($IdCheck1 ,0,3); # "F3" stands for first 3 letters of lastname 



if ( (Sname =~ /SIdCheckl/i )or (Sname =“ /SF3/i) )<; 

Sname = Sname . " " x (8- length(Sname) ); 

SLastName = uc(SLastName) . " " x (25- length(SLastName)); 
SFirstName = uc(SFirstName) . " " x (15- length(SFirstName)); 
SMiddle = uc(SMiddle) . " " x (15- length(SMiddle) ); 

SURL = SURL . (" " x (60- length (SURL ) ) ) ; 

SLastFiMi = uc(SLastFiMi ) . (" " x (27- length($LastFiMi ) )); 
print UserList 

( joi n("", SLastName, SFirstName, SMiddle, SLastFiMi ,$URL,Sname,"\n") ); 

>elsef 



Sname = Sname - " " x (8- length (Sname) ) ; 

SLastName = uc(SLastName) . " " x (25- length(SLastName) ); 
SFirstName = uc($Fi rstName) . " " x (15- length(SFi rstName) ); 
SMiddle = uc(SMiddle) . " " x (15- length(SMiddle)); 

SURL = SURL . (" " x (60- length (SURL) ) ) ; 

SLastFiMi = uc(SLastFiMi ) . (" " x (27- length(SLastFiMi )) ); 
print NoShow 

( join("",SLastName,SFi rstName,SMiddle,$Last F i Mi ,$URL , Sname, "\n") ) ; 

> 

> 



> 
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(HARVEST Module) 

unit ftphl; 



interface 



uses 

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, 
StdCtrls, OleCtrls, NMCT, ExtCtrls, ComCtrls, ISP; 



type 

TForml = class(TForm) 

FTP: TFTP; 

Timerl: TTimer; 

Status: TStatusBar; 

Label 1: TLabel; 

procedure FTPAbortC Sender: TObject ); 
procedure FTPExecute(Sender: TObject); 
procedure FTPNoopC Sender: TObject); 

procedure FTPStateChangedCSender: TObject; State: Smallint); 
procedure DownloadC const getFi le, put Fi le: string); 
procedure Timer IT imer( Sender : TObject); 
procedure FormAct i vate(Sender: TObject); 

procedure FormClose(Sender: TObject; var Action: TCloseAct ion); 
procedure Wai tToAl lowProcessi ng; 



private 

( Private declarations > 
pub l ic 

( Public declarations > 
end; 

var 

Forml: TForml; 
implementation 
(SR *.DFM> 
var 

LogStr:TStringList; 

const 



cRemoteHost 


= 


•131.120.50.206'; 


cPort 


= 


•21'; 


cUser 


= 


' locator' ; 


cPass 


= 


'2nttk4u'; 


cFi leToGet 1 


= 


'userlist.txt ' ; 


cFi leToGet 2 


= 


•currf ill .data'; 


cFi leToGet 3 


= 


'currf i 12. data 1 ; 


cDataDi r 


= 


'c:\thesis\npsd\' ; 


cFi leToWri tel 


= 


cDataDi r + cFi leToGet 1; 


cFi leToWri te2 


= 


cDataDir + 'currid.txt 


cFi leToWri te3 


= 


cDataDir + 'curric2.txt 


cLogDir 


= 


'c:\tempV; 



procedure TForml . FTPAbort (Sender: TObject); 
begin 

Logs tr.add( 'abort event'); 

(WANT TO WRITE OUT TO A LOO 
end; 

procedure TForml . FTPExecuteC Sender: TObject); 
begin 

LogStr.add ( 'execute'); 

end; 

procedure TForml . FTPNoop(Sender: TObject); 
beg i n 
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LogStr.add( 'Noop' ); 



end; 



procedure TForml . FTPStateChanged(Sender: TObject; State: Smallint); 
begin 



with FTP, LogStr do 
case State of 

prcConnect ing : 
prcResolvingHost: 
prcHostResolved : 
prcConnect ed 



add( 'Connecting' ); 
add( 'Connecting' ); 
add('Host resolved'); 
add ( 'Connected to: 1 h 
prcDisconnecting: add( 'Disconnecting' ); 
prcDisconnected : add( 'Disconnected' ); 



RemoteHost); 



end; 



end; 



procedure TForml .Download( const getFi le,putFi le:string); 
beg i n 

Status. simpleText:= 'Downloading ' + getFile + ' 
if ( FTP.protocolstate <> 2) then begin 

LogStr. add( 'Transfer Aborted!'); // do abort recovery. . .emai l 

// notification and logging? 
end 

else begin 

WaitToAl lowProcessing; 

LogStr. addc int tost r( FTP. protocol state)); 

FTP. GetFile (getFile, putFile); 

// give it a chance to get info 
WaitToAl lowProcessing; 

while (FTP. docoutput. state <> 5) do begin 
appl icat ion.ProcessHessages; 
if FTP. docoutput. state = 4 then break; 
end; 

LogStr. add(FloatToStr(FTP. docoutput. bytestotal) + ' bytes total transfered to file 
+ putF i leg- 



end; 

end; 

procedure TForml .T imer1Timer( Sender: TObject); 
begin 

timerl . interval := 5000; 
timerl .enabled := false; 
end; 



procedure TForml .FormAct ivate(Sender: TObject); 
beg i n 

LogStr := TStringList .create; 

Status. simpleText:= 'Connecting to ' + cRemoteHost + ' ...'; 
FTP.connect(cRemoteHost,cPort ); 

While (FTP. State = 1) Or 

(FTP. State = 2) Or 

(FTP. State = 3) do Appl ication.ProcessMessages; 

While (FTP. State = 4) And (FTP.ProtocolState = 0) do Appl icat ion. ProcessMessages; 

// Wait For Connection Response 
// Wait for status change... 

// Check Status Of Control 

Status. simpleT ext := 'Authenticating User: ' + cUser + ' ...'; 

FTP. authenticate (cUser, cPass ); 

//LogStr. add( inttostr( FTP.protocolstate) ); 

Status. simpleText:= 'Deleting old files...'; 

Wai tToA l lowProcessing; 
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DeleteFi le(cF i leToWri tel ); 

DeleteFi le(cFi leToWri te2); 

DeleteFi le(cFi leToWri te3); 
download(cFi leToGetl # cFi leToWri tel ); 
download(cFileToGet2,cFileToWrite2); 
download(cFi leToGet3 # cF i leToWri te3); 

FTP. quit; 

Forml .close; 
end; 

procedure TForml . FormC l ose( Sender: TObject; var Action: TCloseAct ion); 
var F: text File; 

Fi l eName: string; 

beg i n 

fileName := cLogDir + 'FTP.log'; 

AssignFi le(F # FileName); 

ReWri te(F); 

WritelnCF, 'FTP Log on 1 + dateTimeToStr(now)); 

WritelnCF, LogSt r . text); 

CloseFi le(F) ; C Close file, save changes } 

end; 



procedure TForml .Wai tToAl lowProcessing; 
begin 

timerl .enabled := true; 

while (timerl .enabled = true) do appl icat ion.ProcessMessages; 
end; 
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(MERGE Module) 

unit mergel; 

interface 

uses 

Windows, Messages, Syslltils, Classes, Graphics, Controls, Forms, Dialogs, 
Grids, DBGrids, StdCtrls, DBTables, DB, libcrypt, ComCtrls, ExtCtrls; 

type 

TForml = class(TForm) 

Ascii Table: TTable; 

BatchMovel : TBatchMove; 

Table2: TTable; 

Table3: TTable; 

Queryl: TQuery; 

Query2: TQuery; 

Tabled: TTable; 

Databasel : TDatabase; 

Main: TTable; 

Query3: TQuery; 

Label 1: T Label; 

Status: TStatusBar; 

Imagel: T Image; 

procedure ConvertTxtFi lesToDBs; 
procedure CleanCurricData; 

function RemFi rstField(ch:char; var s:string) :string; 
procedure MergeCurricWi thEmai lUrlData; 

procedure FormC l ose( Sender : TObject; var Action: TCloseAct ion); 
procedure OracleBatchUpdate; 
procedure DeleteStudentsFromMain; 
procedure FormAct i vat e( Sender: TObject); 



private 

{ Private declarations ) 
publ ic 

i Public declarations > 
end; 

var 

Forml: TForml; 
implementation 
C$R *.DFM> 
const 

cDataDir = 'C:\Thesis\npsd\ 1 ; 

procedure TForml .ConvertTxtFi lesToDBs; 
begin 

appl icat ion.ProcessMessages; 
try 

Status. simpleText := Converting Curricular Extract File(l)'; 
with ascii Table do begin 
close; 

databasename := cDataDir; 
tabletype := ttascii; 
tablename := 'curric2.txt' ; 
active := false; 
end; 

with BatchMovel do begin 
Source: =asci i Table; 
table2. close; 

table2. databasename := cDataDir; 
table2.tableName:='phase1 '; 

Destinat ion:=table2; 
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Mode: =bat append ; 

AbortOnKeyViol := False; 

KeyViolTableName := cDataDir + 'KEYVI0L1 .DB' ; 
table2.EmptyTable; 
execute; 
table2. close; 
table2. ope^- 
end; 

Status. simpleText := 'Converting Curricular Extract File(l)'; 

// MessageD lg( IntToStr(batchmove1 .MovedCount ) + 1 records read', mt Information, [mbOK] , 0) 
Status. simpleText := IntToStr(batchmove1 .MovedCount ) + 1 records read! + 

•Now Converting Curricular Extract F i l eC 2 ) 1 ; 
appl icat ion.ProcessMessages; 

with ascii Table do begin 
close; 

databasename := cDataDir; 
tabletype := ttascii; 
tablename := 'currid.txt'; 
active := false; 
end; 



with BatchMovel do begin 
Source:=asci i Table; 
table3. close; 

t ab l e3. databasename := cDataDir; 
table3.tableName:='Phase2' ; 

Destinat ion:=table3; 

Mode: =bat append ; 

AbortOnKeyViol := False; 

KeyViolTableName := cDataDir + 'KEYV10L2.DB 1 ; 
table3.EmptyTable; 
table3.open; 
execute; 
table3.open; 
end; 

// MessageD l g( I ntToStr (bat chmovel .MovedCount) + 1 records read', mt Information, [mbOK] , 0) 
Status. simpleText := I ntToStr (bat chmovel .MovedCount ) + 1 records read! + 

'Now Converting UNIX System Extract File'; 
appl icat ion.ProcessMessages; 

with asciiTable do begin 
close; 

databasename := cDataDir; 
tabletype := ttascii; 
tablename := 'userlist.txt' ; 
active := false; 
end; 

with BatchMovel do begin 
Source :=asci i Table ; 
table2. close; 

table2.tableName:= , Phase4a'; 

Dest i nation: =table2; 

Mode: =batappend; 

AbortOnKeyViol := False; 

KeyViolTableName := cDataDir + 1 KEYVIOL4a.DB 1 ; 
table2.EmptyTable; 

//table2.open; 

execute; 

//table2.open; 

end; 

// MessageD lg( I ntToStr (batchmovel .MovedCount) + ' records read', mtlnformat ion, [mbOK], 0) 
Status. simpleText := I ntToStr( batchmovel .MovedCount ) + ‘ records read! -- 1 + 

•Now Eliminating Duplicates in UNIX System Extract'; 
appl icat ion.ProcessMessages; 
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with BatchMovel do begin 
Source:=Table2; 
table4. close; 

table4.databasename := cDataDir; 
table4. tableName:='Phase4b' ; 
table4.tabletype := ttparadox; 

Dest i nation :=table4; 

Mode :=bat append; 

AbortOnKeyVi ol := False; 

KeyViolTableName := cDataDir + 1 KEYVI0L4b.DB 1 ; 

tab l e4 . EmptyT able; 

execute; 

end; 

Status. simpleText := IntToStrCbatchmovel .MovedCount ) + 1 records read!' 

appl i cat i on. ProcessMessages ; 

except 

asci iTable.close; 
table2.close; 
tabl e3. close; 
tabl e4. close; 
halt; 
end; 
end; 



procedure TForml .CleanCurricData; 
var 

f i rst , second, thi rd, fourth, temp: String; 
i,size,cnt: integer; 
existcomma: boolean; 

begin 

Status. simpleText := 'Cleaning Curricular Extract DATA'; 

appl ication. ProcessMessages; 

query 1 .close; 

queryl .open; 

query 1 .first; 

with Table2 do begin 
close; 

DatabaseName := cDataDir; 
tableName:= 1 phase3 1 ; 

EmptyTable; 

end; 

Table2.open; 

while not Queryl. Eof do begin 
Tabl e2. append; 



temp := UpperCase(Trim(Query1 .f ieldbyname( 'name 1 ).asstr ing)); 
size := Length ( temp); 
cnt := 0; 

existcomma := false; 

For i := 1 to size do begin 
if temp[i] = 1 , 1 then 
existcomma := true; 

end; 

if (existcomma) then begin 

Table2 ['Last '] := RemF i rstField( ' , ' , temp); 
temp : = trim(temp); 
size := Length ( temp); 

For i := 1 to size do begin 
if temp[i] = 1 ' then 
inc(cnt); 

end; 



case cnt of 
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0 : beg i n 

Table2 [' Fi rst '] := temp; 

end; 

1: begin 

Table2[' First '] := RemFirstFieldC ',temp); 
Table2['Middle'] := temp; 

end; 



else begin 

Table2[ , First'] := RemFirstFieldC ',temp); 

Table2 ['Middle' ] := RemFirstFieldC ', temp^- 

end; 

end; 

end 

else begin //no comma 

For i := 1 to size do begin 
if temp[i] = ' 1 then 
Inc(cnt); 

end; 

first := ■'; 
second := 1 ' ; 
third := '•; 
case cnt of 
0: begin 

Table2['Last'] := temp; 

end; 

1 : beg i n 

Table2['Last '] := RemFirstFieldC ',temp); 

Table2[' Fi rst '] := temp; 

end; 

2 : beg i n 

first := RemFirstFieldC ',temp); 
second:= RemFirstFieldC *,temp); 
third := trim(temp); 

if ((first = 1 AL ' ) or (first = 'VAN') or (first = 'VON')) 
Table2['Last'] := first + second; 

Table2[' First'] := third; 

end 

else begin 

Table2['Last '] := first; 

Table2['First'] : = second; 

Table2['Middle'] := third; 
end; 

end; 

else begin 

first := RemFirstFieldC *,temp); 
second:= RemFirstFieldC * f temp); 
third := trim(RemFirstField( 1 ' # temp)); 
if ((first = 'AL') or (first = 'VAN') or (first = 'VON')) 
Table2['Last'] := first + second; 

Table2[' First'] := third; 

end 

else begin 

Table2['Last '] := first; 

Table2[' First '] := second; 

Table2 ['Middle'] := third; 
end; 

end; 

end; //case 

end; // if-else comma test 

Table2['Id'] := copy( crypt (Queryl [' ssn'] f '*$'), 3,11)+ copy(Query1 ['ssn'] 
Table2['Mai Icode'] := Queryl [*mai l code'] ; 

Table2['Dept '] := QuerylC'Dept']; 

Table2[' Phone'] := Queryl ['Phone'] ; 

Table2['Title'] := 'Student: ' + Queryl ['curr'] + ' curriculum'; 

Table2['Status'] := 'STUDENT'; 

Table2.post; 
queryl .next; 



then begin 



then begin 



9,1); 
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end; 

Table2. close; 
Tab l e2. open; 



end; 



function TForml .RemFi rstField(ch:char; var s:string) :strmg; 
var 

i,size : Integer; 
s2 : String; 
beg i n 

Setlength(s2,255); 
i := pos( ch,s); 

If i =0 then begin 
RemFirstField := s; 

Exi t; 
end; 

size := ( length (s)-1 ); 

Move(s[i+1], s2[1] # size); 

Set length (s, i-1); 

Set length (s2, size); 

RemFirstField := s; 
s:= s2; 



procedure TForml .MergeCurricWi thEmai lUrlData; 
var 

I , initcount, ful l count, nomatch, fi rstcount: integer; 

LookUpResults rvariant; 

LuLast ,LuFi rst,LuHiddle, LuFinit, LuMini t,LuLFM: string; 
beg i n 

// AT THIS POINT WE WANT TO MERGE WITH THE PERL FILE TO GET EMAIL AND URL 

//***************************** phase 4 merge URL/Email data with Phase3 product 
Status. simpleText := 'Merging Curricular Extract DATA with UNIX Extract DATA'; 
appl ication.ProcessMessages; 

Table3. close; 

Table3.databasename := cDataDir; 

Table3. tablename := ' phase4b.db‘ ; 

Tab l e3. open; 

Table3.f irst; 

Table2.open; 

Table2.fi rst; 
initcount:=0; 
ful Icount :=0; 
f i rstcount :=0; 
nomatch :=0; 

while not table2.eof do begin 

LuLast := Trim(Table2.fieldbyname( 'Last' ).asstring); 

LuFirst := Trim(Table2.fieldbyname( 'First ' ).asstring); 

LuMiddle:= Table2.f ieldbyname( 'Middle' ) .asst ring; 

LuFinit := copy( LuFirst ,1,1); 

LuMinit := copy(LuMiddle,1 , 1 ); 

LuLFM := LuLast + LuFinit + LuMinit; 

i f Table3.Locate( ' Lname; Fname;MI ' , 

VarArrayOf ( [LuLast, LuFi rst, LuMinit] ), [loPartialKey] ) then begin 
Table2.edit; 

Table2['email '] := Table3['emai l '] + '3nps.navy.nri l ' ; 

Table2 Curl '] := TableSC^rl 1 ]; 
inc( ful Icount ); 
table2.post; 



end 

else if Table3.Locate( 'LastFiMi 1 , LuLFM, [loCase Insensitive, loPartialKey] ) then begin 
Table2.edi t; 

Table2['emai l '] := Table3['emai l '] + '3nps.navy.mil'; 
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Table2 [■ url ' ] : = Table3 Curl '] ; 
table2.post; 
inc(initcount); 
end 

else if Table3.Locate( 1 Lname;Fname 1 , 

VarArrayOf ( [LuLast ,LuFi rst] ) , [loPartialKey] ) then begin 
Table2.edi t; 

Table2 [ 1 emai l 1 ] := Table3 C'emai l ■] + 'anps.navy.mil'; 

Table2['url '] := Table3 ['ur l ; 

table2.post; 

inc(f i rs t count ); 

end 

else 

inc( nomatch); 

if table2.fieldbyname( 'middle' ) .asSt ring <> 11 then begin 
table2. edi t; 

table2['middle'] := copy ( tab le2. fieldbyname( 'middle' ) .asString, 1 , 1 ); 
table2.post; 

end; 

table2.next; 



end; 



end; 



procedure TForml . FormC l ose( Sender: TObject; var Action: TCloseAct ion); 
beg i n 

asci iTable. close; 
tabl e2. close; 
table3. close; 
table4. close; 
end; 



procedure TForml .OracleBatchUpdate; 

var I :char; 

begin 

Status. simpleText := 'Updating Oracle Database'; 
appl ication.ProcessMessages; 
for I : = ' A • to 1 Z ' do begin 

Status. simpleText := 'Updating Oracle Database w/ Last names beginning with: ' +1 

QUERY3. CLOSE; 

QUERY3. SQL. CLEAR; 

QUERY3. SQL. ADDC INSERT INTO ":LOC:MAIN" SELECT * 1 + 

'FROM ":NPSD:PHASE3" WHERE LAST LIKE '+ "" + I + '%'"); 

QUERY3.EXECSQL; 

appl ication.ProcessMessages; 

end; 

QUERY2. CLOSE; 

QUERY2. SQL. CLEAR; 

QUERY2. SQL. ADD( 'UPDATE MAIN M SET REGISTERED= ' • 1 " WHERE M.ID = ' + 

'(SELECT FKID FROM REGISTER R WHERE M. ID=R. FKID )'); 

QUERY2.EXECSQL; 

appl ication.ProcessMessages; 

end; 

procedure TForml .DeleteStudentsFromMain; 
var s:string; 
beg i n 

// The runs a delete query on the Main table... it deletes all student records. 

// The query. sql. text = ' DELETE FROM "MAIN" WHERE "Status" = 'STUDENT' ' 

Status. simpleText := 'Deleting Old Student Data'; 
appl icat ion. ProcessMessages; 

QUERY2. CLOSE; 

QUERY2. SQL. CLEAR ; 

Query2. sql. add( 'DELETE FROM MAIN WHERE STATUS= " STUDENT '" ); 
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Query2.execsql; 
query2. close; 
end; 

procedure TForml .FormActivateC Sender: TObject); 
beg i n 

ConvertTxtFi lesToDBs; 

CleanCurricData; 

MergeCurricWi thEmai lUrlData; 
DeleteStudentsFromMain; 

OracleBatchUpdate; 

Appl i cat ion. Terminate; 



end. 

end. 
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APPENDIX C. NPS LOCATOR MAIN SOURCE CODE MODULE 



This Appendix contains the main module of the NPS Locator Prototype. This module 
provides all the business logic and Web application functionality. 



unit NPSf ; 

interface 

uses 

SysUtils, Messages, Classes, Graphics, Controls, Forms, Dialogs 
, Buttons, StdCtrls, Menus, ExtCtrls 
(SIFDEF WIN32} 

, Windows 
{SELSE} 

, WinProcs, WinTypes 
CSENDIF} 

, Toolbar 

, TpMenu, TpMemo, WebMemo, Combobar 

, WebTypes, WebVars, WebBase, WebCore, WebApp, WebCall 
, Webmenu, HtmlBase, HtmlCore, HtmlSend, Weblnfo, WebBrows, 

UpdateOk, WeblniFL, WebHttp, WebServ, Ini Link, Webconst 
# WebForm, Restorer, TpApplic, TpLabel, WebLink, WebPage, WebPHub, DB, 
DBTables, WdbLink, WdbScan, WdbGrid, WdbSorce, DBCtrls, Grids, DBGrids, 
TblRetry, Webtbl, WebMail, WebSock, ucstring; 

type 

TWebAppNPS = class(TWebAppForm) 

StatusBarl: TtpStatusBar; 

StatusPanell : TtpStatusPanel; 

WebAppOutput : TWebAppOutput; 

Weblnfo: TWeblnfo; 

WeblniFi leLink: TWeblni Fi leLink; 

Webserver: TWebServer; 

WebBrowser: TWebBrowser; 

WebCommandL i nel : TWebCommandL i ne; 

WebAppNPS: TWebApp; 

WebSessionO: TWebSession; 
tpComponentPanel 1 : TtpComponentPanel ; 
tpAppRolel: TtpAppRole; 

FormRestorerl : TFormRestorer; 

DoMenuBarFi le: TtpDfmMenuItem; 

DoExit: TtpDfmMenuI tem; 

DoMenuBarHelp: TtpDfmMenuItem; 

DoContents: TtpDfmMenuItem; 

DoTopicSearch: TtpDfmMenuI tem; 

DoHowtouseHelp: TtpDfmMenuItem; 

DoTtpDfmMenuI tem: TtpDfmMenuItem; 

DoAbout: TtpDfmMenuItem; 

DoActionComponents: TtpMenuItem; 

DoWebPages: TtpMenuItem; 

WebMenul: TWebMenu; 
tpComboBarl: TtpComboBar; 

ToolBar2: TtpToolBar; 

DoMenuItemView: TtpMenuItem; 

DoMenuItemTool : TtpMenuItem; 

DoMenuItemVerb: TtpMenuItem; 

DoMenuItemldle: TtpMenuItem; 
tpToolButtonBrowser: TtpToo l Button; 
tpToolButtonMemo: TtpToolButton; 
tpToolButtonAct ivated: TtpToolButton; 
tbBlankPage: TtpToolButton; 
tbUserPage: TtpToolButton; 
tbMemoPage: TtpToolButton; 

Notebook: TNotebook; 
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WebHtmlMemol : TWebHtmlMemo; 
tpLabell: TtpLabel; 
tpLabel2: TtpLabel; 

SurferTbl: TTable; 

DataSourcel : TDataSource; 

WebDataSourcel : TWebDataSource; 

Queryl: TQuery; 

BatchMovel: TBatchMove; 
registertbl: TTable; 

NPS_ANSWER: TWebPage; 

NPS_DETAI L : TWebPage; 

DBGridl : TDBGrid; 

DBNavigatorl : TDBNavi gator; 
wgridl: TWebOataGr id; 

NPS_ADMIN: TWebPage; 

Editl: TEdit; 

Memol : TMemo; 
wgrid2: TWebOataGr id; 

NPS_ANSWERREG: TWebPage; 

NPS_DETAI LREG: TWebPage; 

WebSockl: TWebSock; 

WebMaill: TWebMail; 

NPS_FBREGISTER: TWebPage; 

DataSource2: TDataSource; 

NPS_DETAILL0G: TWebPage; 
main: TTable; 

NPS^FBUPDATE: TWebPage; 

NPS_HOMEPAGE: TWebPage; 

NPS^LOGINPG: TWebPage; 

NPS_FBUPLOADPIC: TWebPage; 

NPSJJPLOADPIC: TWebPage; 

NPS_LOGUPDATE: TWebPage; 

NPS_CHGPASS: TWebPage; 

NPS_FBCHGPASS: TWebPage; 
npsd: TD at abase ; 

procedure SelectPage(Sender: TObject); 
procedure FormCreateCSender : TObject); 
procedure QuerylAf terOpen(DataSet: TDataSet); 
procedure Grid1HotField(Sender : TWebOataScan; aField: TField; 
var s: string); 

procedure Grid2HotField(Sender : TWebOataScan; aField: TField; 
var s: string); 

procedure Queryl BeforeOpen(DataSet: TDataSet); 
procedure NPS_ANSWERSection(Sender: TObject; Section: Integer; 
var Chunk, Options: string); 

procedure WebAppNPSEventMacroC Sender: TWebOutputApp; const aMacro, 
aParams, alD: string); 

procedure NPS_DETAILSection(Sender: ‘TObject; Section: Integer; 
var Chunk, Options: string); 

procedure NPS_ANSWERREGSection(Sender: TObject; Section: Integer; 
var Chunk, Options: string); 

procedure NPS_DETAILREGSect ion(Sender : TObject; Section: Integer; 

var Chunk, Options: string); 
procedure NPS_FBREGISTERExecute(Sender : TObject; 
var Continue: Boolean); 

procedure NPS_DETAILLOGSect ionCSender: TObject; Section: Integer; var Chunk, 
Options: string); 

procedure NPS_DETAILLOGExecute(Sender: TObject; var Continue: Boolean); 

procedure NPS_FBUPDATEExecute(Sender: TObject; var Continue: Boolean); 
procedure NPS_HOMEPAGEExecute( Sender: TObject; var Continue: Boolean); 
procedure NPS_LOGINPGExecDone(Sender: TObject); 
procedure NPS_HOMEPAGESect ionCSender: TObject; Section: Integer; 

var Chunk, Options: string); 
procedure NPS_FBUPLOADPICExecute(Sender : TObject; 
var Continue: Boolean); 

procedure NPS_UPLOADPICExecute(Sender: TObject; var Continue: Boolean); 
procedure NPS_LOGUPDATESect ionCSender: TObject; Section: Integer; 
var Chunk, Options: string); 

procedure NPS_LOGUPDATEExecute(Sender: TObject; var Continue: Boolean); 
procedure NPS_FBUPLOADP I CSect ionCSender: TObject; Section: Integer; 
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var Chunk, Options: string); 

procedure NPS_CHGPASSExecute(Sender: TObject; var Continue: Boolean); 
procedure NPS_FBCHGPASSExecute( Sender: TObject; var Continue: Boolean); 

private 

{ Private declarations } 

function getNextDBFi lename.-String; 

procedure SetSurf erDb(Tbl :TTable); 

procedure SetDBEnv(Tbl :TTable); 

function GeneratePassword :string; 

function GetLiteraULiteralName :string) :str ing; 

function GetFormLiteral(LiteralName .-string) :string; 

Procedure Put Li teral(Li teralName,Li teralVa lue: string) ; 
procedure BounceTo( PagelD: string ); 

{upload utilities} 
procedure UpLoadllserFi les; 

procedure SaveUploadFi le(const Uploadlnfoistring; 

var NewFi leName,ClientFi leName:String); 
procedure ForceFi leRename(const oldName,newName:string); 
public 

{ Public declarations } 
end; 

var 

WebAppNPS: TWebAppNPS; 
implementation 
{SR *.DFM> 



{ } 

var 

nextTempNum: integer; { used to cycle thru temp table names } 

ini tF lag: Boolean; { flag for use with temporary workaround } 



const 

maxSimulQueries=25; 
cPageldFrontDoor = 'homepage'; 
cWebSvrDir = 'C:\Website\htdocsV; 
clmageDir = cWebSvrDir + 'npsd\img\'; 
cDataDir = 'C:\Thesis\npsd\'; 



{ } 

procedure TWebAppNPS. FormCreateC Sender: TObject); 
beg i n 

SelectPage(tbBlankPage); 

end; 

{ - } 

procedure TWebAppNPS.Se l ectPage( Sender: TObject); 
beg i n 

with TtpToolButton(Sender) do begin 
No t eBook. Page Index :=Tag ; 

Down:=True; 

end; 

end; 

f unction TWebAppN PS. getNextDBFi lename:String; 
beg i n 

i ncC NextTempNum) ; 

if NextTempNum>maxSimulQueries then NextTempNum:=1; 
result := , qry , +intToStr(NextTempWum)+' .db' ; 
end; 

procedure TWebAppNPS .QuerylAf terOpen(DataSet : TDataSet); 
beg i n 

with BatchMovel do begin 
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Source; =Query1; 

SurferTbl .close; 

SurferTbl . tableName:=getNextDBFi lename; 

Desti nation: =SurferTbl ; 

Mode :=bat Copy; 
execute; 
queryl .close; 

SurferTbl .open; 
end; 

WebAppNPS. Literal ['DBName'] := SurferTbl . tablename; 

SetDbEnv(SurferTbl); 

end; 

procedure TWebAppNPS.GridlHot Field(Sender: TWebOataScan; 

aField: TField; var s: string); 
var 

desc : string; 
g:TWebOataGrid; 

tc:TDataSet; { tc stands for Table Cursor, a bit of a trad from ObjectPal > 
idiString; 
begin 

desc := aField. asString; 

g:=TWebOataGrid(Sender); { so we can reuse this proc for multiple grids > 

tc :=aFi eld. DataSet ; 

id:=tc.f ieldByName( 'Id' ). asString; 

{JUMP is a bui It- in WebHub macro. Syntax is: JUMP jpageld, command | vis iblePh rase > 
if compareText(aField.f ieldName, 'Email')=0 then 

s:='<TD><A HREF=mai l to: 1 + afield. asstring + •>' + afield. asst ring 
+ 1 </A>/TD> 1 

else if compareTextCaField.f ieldName, 'Last')=0 then 

s:='<TD>' + '%=JUMP |detai l , '+ id + 1 | 1 + desc + '=%' 

else 

s:= 1 <TD><A HREF = 1 + afield. asstring + •>' + afield. asstring + '</A>/TD>' 



end; 



procedure TWebAppNPS.Grid2HotField( Sender; TWebOataScan; 

aField: TField; var s: string); 
var 

desc : string; 
g:TWebDataGrid; 

tc:TDataSet; { tc stands for Table Cursor, a bit of a trad from ObjectPal > 
id:String; 
begin 

desc := aField. asString; 

g:=TWebDataGrid(Sender); { so we can reuse this proc for multiple grids > 

tc:=aFi eld. DataSet; 

id:=tc.f ieldByName( 'Id' ). asString; 

{JUMP is a built-in WebHub macro. Syntax is: JUMP|pageId,command|visiblePhrase } 
if compareText(aField.f ieldName, 'Last')=0 then begin 
if notCtc.f ieldbyname( 'Registered 1 ) .value = 1 1 ' ) then 
s: = , <TD>' + '%=JUMP jdetai Ireg, •+ id + 1 1* + desc + ,= %' 
else 

s:='<TD>* 1 + desc; 
end 
else 

s:= 1 <TD><A HREF = 1 + afield. asString + •>' + afield. asString + , </A>/TD> 1 ; 

end; 



procedure TWebAppNPS. Queryl Bef oreOpenCDataSet : TDataSet); 
var srchkeys: integer; 
tok:string; 

begin 

tok := '%•; 
srchkeys := 0; 

with TQuery( DataSet ) do begin 
sql .clear; 

sql.addC 'SELECT * FROM MAIN' ); 
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if WebAppNPS. Webserver. FormL itera l s.Va lues ['Last' 3 <> 11 then begin 
sql.addC 'WHERE Last LIKE '); 

sql.addC'''' + uppercase(WebAppNPS. Webserver. FormL i terals. Values ['Last '3 )+ tok + 

inc( srchkeys); 
end; 

if WebAppNPS. Webserver. FormL i terals. Values ['Dept '3 <> " then begin 
if srchkeys = 0 then begin 
sql.addC WHERE Dept = '); 

sql.addC ' 1 ' ' + WebAppNPS. Webserver. FormL it era Is. Va l ues[' Dept '] + ' ' ' ' ); 
inc(srchkeys); 
end 
else 

sql.addC 1 and Dept = 1 + 11 11 + (WebAppNPS. Webserver. FormLi terals. Values ['Dept'] )+ 

end; 

if (WebAppNPS. Webserver. FormL i ter a l s.Va l uesC'emptype 1 ] <> 'ALL') and 

not (WebAppNPS. Webserver. FormL itera l s.Va l uesC'emptype 1 ] = ■') then begin 
if srchkeys = 0 then begin 

sql.addC WHERE Status = '); 

sql.addC 1,1 1 + WebAppNPS. Webserver. FormL itera l s.Va l uesC'emptype'] + ''''); 
end 
else 

sql.addC ' and Status ='+''''+ 

WebAppNPS. Webserver. FormL it era Is.Values [ 1 emptype' ]+ " ' ' ); 
end; 

sql.addC ' ORDER BY Last, First'); 

end; 

memol.text := query!. text; 

end; 

procedure TWebAppNPS. NPS_ANSWER Sec t ion( Sender : TObject; Section: Integer; 

var Chunk, Options: string); 
beg i n 



if section>1 then exit; 

WebAppNPS. Li teral [ ' wgr idl .Di splaySet ' ]:= 'normal'; 
if WebAppNPS. Comma nd=cCheckboxes then begin 

{Reset the query when we arrive on this page, coming from homepage) 

{Leave it alone if command is something like grid. next > 

Queryl .close; 

Query! .open; 
end; 

if ( l eng th( WebAppNPS. Command) = 1) and (WebAppNPS. Command Cl 3 in C ' A ' . . ' Z '3 ) then begin 
WebAppNPS. Webserver. FormL itera l s.Va lues C Last' ] := WebA ppN PS. Command; 

Query! .close; 

Query! .open; 
end; 

{get the currect db for the current surfer) 

SetSurf erDbCSurferTbl ); 

end; 

procedure TWebAppNPS. WebAppNPSEventMacroCSender: TWebOutputApp; 

const aMacro, aParams, alD: string); 
var 

fld:TField; 
lMacro:String; 
s : St ring; 
begin 

lMacro:=lowercase(aMacro); 

{ create the meaning of the getfield macro ) 

{ usage: getf ield|f ieldname -- see mypages.htm ) 
with WebAppNPS. We bOut put do begin 
if IMacro = 'getfield' then begin 
with SurferTbl do begin 

f ld:=f indField(aParams); { aParams is info after vertical bar, i.e. fieldname ) 
if f ld<>ni l then begin 
s:=f Id.asString; 
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Send(s); 

end 

else 

SendComment( 'Invalid fieldname: 1 + aParams ); 
end; 
end 

else if iMacro = 'getf ieldreg' then begin 
with registerTbl do begin 

f Id: =f indField( aParams); { aParams is info after vertical bar, i.e. fieldname > 
if fldonil then begin 

if (f ld.asString=' 1 ) and (comparetext(aParams, 'picture' )=0) then 
SendCnopic.gif ) 
else begin 

s:=f Id.asString; 

Send(s); 

end; 

end 

else 

SendComment( 'Invalid fieldname: 1 + aParams ); 
end; 
end 

else if IMacro = 'getf ieldmain' then begin 
with main do begin 

f Id: =f indField(aParams); { aParams is info after vertical bar, i.e. fieldname > 
if fldonil then begin 
s:=f Id.asString; 

Send(s); 

end 

else 

SendCommentC 'Invalid fieldname: ' + aParams ); 
end; 
end 

else begin 

SendComment ( 'Invalid custom macro event: ' + aMacro ); 
end; 
end; 

end; 



procedure TWebAppNPS.NPS_DETAILSection( Sender: TObject; Section: Integer; 

var Chunk, Options: string); 
var 

s,user,picf i lename:string [128] ; 
begin 

if section > 1 then exit; 

{our job here is just to locate to the correct record > 

s := webcommandl inel .mcommand; 

SetSurferDb(SurferTbl ); 

SurferTbl. locateC ' Id' ,s, [] ); 

{the surfer table should include the registertbl (i.e., the query should execute 
but this is a quick an outer join on main.db with registertbl .db. then we can 
get rTd of the getf ieldreg macro (I think?)...} 
if not (Registertbl . locate( 'FkID',s,[])) then 

Registertbl . locate( ' FkID ', 'blank 1 ,[] ); // this is a temp fix for those 

// who are not registered 
// it points to a blank record 
// in the register tbl 

end; 

procedure TWebAppNPS. Set Surf erDb(Tbl :TTable); 
beg i n 

if Tbl . tablename = WebAppNPS.Li teral ['DBName'] then exit; 

Tbl .close; 

Tbl. tablename := WebAppNPS. Li teral ['DBName'] ; 

Tbl .open; 

SetDBEnv(Tbl); 

end; 
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procedure TWebAppNPS. SetDBEnvCTbl :TTable); 
begin 

with Tbl do begin 

fieldByNameC 'Last ' ) .displayLabel :=' LAST NAME' ; 
fieldByNameC First' ) .displayLabel :=' FIRST NAME ' ; 

fieldByNameC 'Emai l ' ) .displayLabel :=' <IMG SRC=%=imageDi r=%mai l to.gi f> EMAIL ' ; 
f ieldByNameC 'Phone' ) .displayLabel :='<IMG SRC=%=imageDi r=%phone1 .gif>PHONE'; 
f ieldByNameC 'Middle' ) .displayLabel : = * M I ' ; 
f ieldByNameC 'URL ' ). displayLabel :=' HOMEPAGE CURL)'; 

{set hot field} 

fieldByNameC 'Last' ) . tag:=HotFieldTag; 
f ieldByNameC 'Emai l ' ) . tag:=HotFieldTag; 
fieldByNameC 'URL 1 ).tag:=HotFieldTag; 
end; 
end; 

procedure TWebAppNPS.NPS_ANSWERREGSect ionC Sender: TObject; 

Section: Integer; var Chunk, Options: string); 
begin 

if section>1 then exit; 

WebAppNPS. Literal [ ' wgr id2.DisplaySet ' ]:= 'normal'; 
if WebAppNPS. Command=cCheckboxes then begin 
{Reset the query when we arrive on this page, coming from homepage} 

{Leave it alone if command is something like grid. next } 

Query 1 .close; 

Queryl .open; 
end; 

{get the currect db for the current surfer} 

SetSurf erDbCSurferTbl ); 
end; 

procedure TWebAppNPS . NPS_DETAI LREGSect i onC Sender : TObject; 

Section: Integer; var Chunk, Options: string); 
var 

s: st ring [128] ; 
begin 

if section>1 then exit; 

// I need this here so that the conditional will work properly 
WebAppNPS. Litera l [ ' Fai IRegister ' 3 : = "; 

{our job here is just to locate to the correct record } 



//* VERY IMPORTANT!! THIS LATER NEEDS TO BE THE MAIN DATABASE ON THE DEC. ..NOT 
//* THE TEMP QRY*.DB TABLES!!!! SAME GOES FOR THE OTHER DETAIL "ONSECTION" 

//* PROCEDURE!!!!!!!!! 



s := webcommandl inel .mcommand; // we are using webCommandLinel instead of Webapp. command 
WebAppNPS. Li teral ['MainID '3 := s; // because the webapp. command translates to uppercase 
SetSurferDbCSurferTbl); 
with SurferTbl do begin 
locateC 1 Id' ,s, [] ); 
end; 
end; 

procedure TWebAppNPS. NPS_FBREG I STERExecuteC Sender: TObject; 

var Continue: Boolean); 
var 

surferEMai l , password: string ; 
begin 

surferEMai l :=WebAppNPS. Literal ['emai Ireg'] ; 
if surferEMai l =' ' then begin 
with WebAppNPS do begin 

SendStringC 'You have to enter your email address !<p>' ); 
continue:=False; 



57 



end; 

end 

else 

with registertbl do begin 
open; 

WebAppNPS. Li teral [ 1 Fai l Register 1 ] := 11 ; 
if f indkeyC [surferEmai l] ) then begin 

WebAppNPS. Li teral [ 1 Fai [Register 1 ]: = 1 T 1 ; 

BounceToC 'Detai IRegFai l ' ); 

end 

else begin 

password := generatePassword; 

Should use the dynamic creation of a query and then use SQL Insert because 
// another surfer could change the record pointer. .. leaving you with update 

//**** anomalies ... this really shouldn't be a problem if we are appending.. 

// right??? 

append; 

fieldbynameC 'Password' ).asSt ring := password; 
f ieldbyname( ' ID * ) .asString := trim(surferEmail); 
fieldbynameC ' Fkl D ' ).asString := WebAppNPS. Li teral [ 'Mai nID '] ; 
fieldbynameC 'activated' ). value := false; 
post; 

// What if mail fails??? should I use expiration date... or some kind of 
// exception on email failure???? 
with webmaill do begin 
Mai Ito. clear; 

Mai l to.addCsurferEmai l ); 

Lines. clear; 

Lines. addC 'Once you login your account will be activated'); 

Lines.addC 'Your Login is: ' + surferEmai l ); 

Lines. addC 1 Your password is: ' + password); 

subject := 'Registration Information'; 
execute; 
end; 
end; 
end; 



end; 



// This is not a sophisticated password generator. .. i t is used only to demonstrate 
// the concept within this application's environment and it serves the purpose, 
function TWebAppNPS. GeneratePassword : string; 
var 

I: Integer; 

Pass: string; 
begin 

Random i ze; 

Pass : = 1 ' ; 

for I := 1 to 6 do begin 
Pass := Pass + chrCRandomC26)+65); 
end; 

generatePassword := Pass; 
end; 

procedure TWebAppNPS . NPS_DET A I LLOGSect i onC Sender : TObject; Section: Integer; 

var Chunk, Options: string); 
var s .-string; 
begin 

if section > 1 then exit; 

// probably should use a unique query here. . .another surfer could change the 
// position of the record pointer. You should create a query on the fly??? and 
// either assing values to literals and "free" the query... or ..."free" the Query 
// using the "onexecdone" event?! C Remember. . .you will also have to change the 
// getfields macros. . .eeee can we do this???) Maybe we don't have to use getfields 
// we can just use the l i teral s. . .then use a query to update.... 

s := registertbl .fieldbynameC 1 FkID' ). asstring; 
main. locateC ' ID ' ,s, [] ); 
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end; 



procedure TWebAppNPS.NPS_DETAILLOGExecute( Sender: TObject; 

var Continue: Boolean); 
var s: st ring; 
begin 

memol.text := 'lok= 1 + WebAppNPS.Li teral [' LoginOk'] + ' loginPend= ' + 

WebAppNPS. Li teral ['LoginPending'] + 1 get l i t ( login)= 1 + get l i teral ( 1 login 1 ); 

if not< WebAppNPS. Li teral ['LoginOk'] = 'TRUE') and 

not (WebAppNPS. Li teral ['LoginPending'] = 'TRUE') then begin 
BounceT o ( ' L og i nPg ' ) ; 
exit; 
end; 

if not (WebAppNPS. Li teral ['LoginPending'] = 'TRUE') then 
ex i t ; 

CWe only want to do this if the user is trying to login} 
s:= getLiteraK 'Login' ); 

if not( registerTbl . locate( 1 ID' f s, [locaseinsensitive] )) then begin 
BounceTo( 'LoginFai l ' ); 

end 

else if registerTbl . fieldbynameC password' ).asstring <> WebAppNPS.Li teral ['password' ] then begin 
BounceTo( 'LoginFai l ' ); 

end 

else 

WebAppNPS.Li teral ['LoginOk'] := 'TRUE'; 

WebAppNPS. Li teral [ 'LoginPending'] := 'FALSE'; 
end; 



procedure TWebAppNPS.NPS_FBUPDATEExecute( Sender: TObject; 

var Continue: Boolean); 
var updateQry:TQuery; 
beg i n 

if WebAppNPS.Li teral ['LoginOk'] <> 'TRUE' then begin 
BounceTo( 'Login' ); 
ex i t ; 
end; 

updateQry := T query. Create( Self ); 

with updateQry do begin ^^************************************* 

databasename := 'locator'; // make this a constant so we only have 

// to change once. 

//updatemode := [wherekeyonly] ; 
sq l .add( 'update REGISTER '); 

sql.addCset URL2 = "' + getFormLi teral( 'url2' ) + ''','); 
sql.addC PH0NE2 = "' + getFormLi teral ( 'phone2' ) + ); 

sql.addC FAX2 = 111 + getFormLi teral( ' fax2' ) + ); 

sql.addC COMMENTS = "' + getFormLi teral ( 'comments' ) + ); 

sql.addC ACTIVATED = "1" ' ); 
sql .add( 'where ID = "' + getLiteraK ' login' ) + '"'); 

memol.text := sql. text; 
exec sql; 
close; 
sql .clear; 

sql.addC update MAIN m set m. registered = "1" '); 
sql.addC where m.id = (select FkID from REGISTER '); 
sql.addC where ID = '" + getLiteraK 1 login 1 ) + ''')'); 

memol.text := sql. text; 
execsql ; 
free; 

end; 

end; 

procedure T WebAppNPS. NPS_HOMEPAGEExecute( Sender: TObject; 

var Continue: Boolean); 
beg i n 
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if (UebAppN PS. Command = 'LOGOUT') then begin 
WebAppN PS. Literal ['LoginOk'] := 'FALSE 1 ; 

UebAppNPS.Li teral [ ' LoginPending ') := 'FALSE'; 
editl.text := editl.text + 'logout'; 
end; 
end; 

procedure TWebAppNPS. NPS_LOG I NPGExecDone( Sender: TObject); 
begin 

WebAppNPS. Literal ['LoginPending'] := 'TRUE'; 
end; 

procedure TWebAppNPS. NPS_HOMEPAGESection(Sender: TObject; Section: Integer; 

var Chunk, Options: string); 
begin 

if section > 1 then 
exit; 

if (UebAppN PS. Command = 'LOGOUT') then begin 
WebAppNPS. Li teral ['LoginOk'] := 'FALSE'; 

WebAppNPS. Li teral ['LoginPending'] := “FALSE'; 
editl.text := editl.text + ’logout'; 
end; 
end; 

{Utility Functions} 

f unct i on TWebAppNPS . Ge t L i t e ra l ( L i te ra l N ame : st r i ng ): string; 



{Read a literal } 

begin 

result := WebAppNPS. Li teral [Li teral Name] ; 

end; 

{ } 



function TWebAppNPS. GetFormLi teral (Li teral Name: string ) : string; 

{read a form literal} 
begin 

result := WebAppNPS. Webserver. FormLitera Is. Values [Li teralName] ; 

end; 

Procedure TWebAppNPS .PutLiteraKLitera l Name , L i t e ra l Va l ue : st r i ng ) ; 

{Add or update a WebApp literal} 
beg i n 

WebAppNPS. Li teral [Li teralName] := Li teralValue; 
end; 

procedure TWebAppNPS . BounceT o( PagelD .‘String); 
begin 

webappoutput .sendbounceto(webappnps.cgical ler + '?nps:' + PagelD + ':' + 

i nt t os t r ( webappnps . sess ion)) ; 

end; 



TESTING AREA FOR UPLOAD ****************} 



procedure TWebAppNPS. UpLoadUserFi l es; 

{looks for the source and companion files for this job } 

var 

upllnfo, ThisEntry : string; 

NewFileName, Cl ient F i leName: string; 

JobFileType : string; 

begin {save uploaded files} 

{Ue don't want to do anything if we didn't get here from the send page} 
{loop over the list of files to upload } 

with Webserver. webini do begin 
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ThisEntry := 'uploadf i le“ ; 
section := 'Form File'; 
entry := ThisEntry; 
upllnfo := StringValue; 
end; 

memol.text := uplinfo; 

// Should use a constant (or ini file) for Webserver path!! 

NewFileName := clmageOir + get l i tera l ( ' Login 1 ); 

if upllnfo <> 11 then begin 

SaveUploadFi le(upl Info, NewFi leName,Cl ientFi leName); 
end 

else begin 

WebAppNPS .WebOutput . Send 

( '<center> <font size=5><b> No File has been 1 + 

' uploaded -- you must enter a valid gif or jpeg picture file' 

+ '</b></font></center><br> ' ) 

end; 

end; 

procedure TWebAppNPS. SaveUploadFi l e( const Uploadlnforstring; 

var NewFi leName, Cl ientFi leName:String); 
const MAXLEN=255; 
var 

Name, EMail, Desc : string; 

UploadFi leName, ServerFi leName: string; 

Fi leSi ze, Fi lesType, Fi lesTypeTest : string; 
ws,wsl,wsr : string; 

Entry,StringValue:string; 

FileToDelete :array[0. .255] of char; 

UploadFi l e: file; 

PicOK: boo lean; 
sistring; 

begin 

{This code relies heavily upon some very handy string 
processing a parsing routines in the ucstring.pas unit 
of the complete TPack code > 

{The following comment contains a sample value for Uploadlnfo:} 

{ 

[C:\WebSite\cgi-temp\66ws.001] 46 text/plain binary [C:\PROJECT\README.TXT] 

> 

memol.text := memol.text + ' ' +UploadInfo; 
ws := Uploadlnfo; 

Spl itString(ws, '] ' ,wsl,ws); 

ServerFi leName :=RightOf< ' [' ,wsl); 
memol.text := memol.text + ' ' + serverFi lename; 

Spl itString(ws, 1 [' ,wsl,wsr); 

Cl ientFi leName := LeftOf ( '] ' ,wsr); 

wsl:= TrimLeft(wsl); 

Spl itString(wsl , 1 ' , Fi leSize, Fi lesType); 

Fi lesTypeTest := trim(Lef tOf ( ' ' , Fi lesType)); 

PicOK := False; 

if (Fi lesTypeTest = 'image/gif') then begin 
newfi lename := newfi lename + 1 .gif'; 

PicOK := TRUE; 
end 

else if (Fi lesTypeTest = ' image/ jpeg ' ) then begin 
newfi lename := newfi lename + '.jpg'; 

PicOK := TRUE; 
end; 

if PicOK then begin 

ForceFi leRename(serverFi lename, NewFi leName); //should have error checking here 
WebAppNPS .WebOutput . Send 

( '<center> <font size=5><b> F i l e= ’ + Cl ientFi leName + '<br> has been '+ 
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•successfully uploaded and saved as 1 + ExtractFi lename(newfi lename) 
+ 1 </b></font></center><br> * ); 
s:= get l i teral( 'Login' ); 
with registertbl do begin 
locateC ' ID' ,s, [] ); 
edit; 

FieldbynameC 'picture' ).asstring:= ExtractFi lename(newf i lename); 
post; 



end 

else 

WebAppNPS . WebOutput . Send 

( '<center> <font size=5><b> F i l e= ' + C l ientFi leName + '<br> has not been uploaded because 
•it was not a gif or jpg </b></font></center><br> ' ); 



end; 



procedure TWebAppNPS. NPS_FBUPLOADP I CExecuteC Sender : TObject; 

var Continue: Boolean); 
begin 

if WebAppNPS. Li teral [' LoginOk'] <> 'TRUE' then begin 
BounceToC 1 Login' ); 
ex i t ; 
end; 

uploaduserf i les; 
end; 

procedure TWebAppNPS. NPSJJPLOADP I CExecuteC Sender : TObject; 

var Continue: Boolean); 
begin 

if WebAppNPS. L i teral [' LoginOk'] <> 'TRUE' then begin 
BounceToC ' Login' ); 
exi t; 
end; 
end; 

procedure TWebAppNPS. NPS_LOGUPDATESection( Sender: TObject; 

Section: Integer; var Chunk, Options: string); 
var s: string [128] ; 
begin 

if section > 1 then exit; 

// probably should use a unique query here. . .another surfer could change the 
// position of the record pointer. You should create a query on the fly??? and 
// either passing values to literals and "free" the query... or ..."free" the Query 
// using the "onexecdone" event?! (Remember. . .you will also have to change the 
// getfields macros. . .eeee can we do this???) Maybe we don't have to use getfields 

// we can just use the l i terals. . . then use a query to update 

s:= get Li teral ( 'Login' ); 
registertbl . locateC 1 ID' ,s, [] ); 
s := registertbl. fieldbynameC ' Fk I D ' ).asstring; 
main. locateC ' ID' ,s, [] ); 



end; 

procedure TWebAppNPS. NPS_LOGUPDATEExecute( Sender: TObject; 

var Continue: Boolean); 
begin 

if WebAppNPS. L i teral [' LoginOk'] <> 'TRUE' then begin 
BounceToC 'Login' ); 
ex i t ; 
end; 
end; 



procedure TWebAppNPS. Force Fi leRenameCconst oldName,newName:string); 
begin 

if DeleteFi le(pchar(newName))then //I shouldn't have to type cast as PChar!!! 
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editl.text := ‘delete’; 
if RenameFi le(oldName,newName) then 
editl.text := editl.text + 'rename'; 

end; 

procedure TWebAppNPS.NPS_FBUPLOADPICSection(Sender : TObject; 

Section: Integer; var Chunk, Options: string); 
var s:string; 
beg i n 

if section > 1 then exit; 
s:=get literal ( ‘ login' ); 
registertbl . locate( ' id' ,s, [] ); 
end; 

procedure TWebAppNPS.NPS_CHGPASSExecute( Sender: TObject; 

var Continue: Boolean); 
beg i n 

if WebAppNPS. Li teral [' Log inOk'] <> 'TRUE 1 then begin 
BounceTo( 1 Login* ); 
exit; 
end; 
end; 

procedure TWehAppNPS.NPS_FBCHGPASSExecute( Sender: TObject; 
var Continue: Boolean); 
var s:string; 
beg i n 

if UebAppNPS.Li teral ['LoginOk'] <> ‘TRUE’ then begin 
BounceTo( 'Login' ); 
ex i t ; 
end; 

if getFormLi teral( 'chpassl ' ) <> getFormLi teral( 'chpass2' ) then 
BounceTo( 'ChgPassFai l 1 ) 
else begin 

s:= getLi teral( 'Login' ); 

editl.text := s + ' ' + getFormLi teral < ‘chpassl ' ); 
with registertbl do begin 
locate( ' Id' ,s, [] ); 
edit; 

fieldByName( 'password' ) .asString := getFormLi teral (' chpassl ' ) 
post; 
end; 
end; 
end; 



end. 
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